Apple släpper iOS 6 beta 4

När du begär åtkomst till Facebook-konton är den enda nyckel som krävs i din alternativordbok ACFacebookAppIdKey. ACFacebookPermissionGroupKey ochACFacebookAppVersionKey är nu föråldrad.Om du begär ett skriftligt tillstånd nedan ACFacebookPermissionsKey, Såsom publish_streammåste du ange ett värde för ACFacebookAudienceKey, som kan vara en avACFacebookAudienceEveryone, ACFacebookAudienceFriends, eller ACFacebookAudienceOnlyMe.

FAST: När en app är i ett nytt sekretessläge och försöker presentera en ABNewPersonViewController, kan användaren inte avvisa den vykontrollanten korrekt, även om användaren tillåter åtkomst till kontakter. Användaren måste tvinga avsluta appen och starta om.

Begär åtkomst till kontakter:

• Användare kan bevilja eller neka åtkomst till kontaktdata per app. För att begära tillgång till kontaktuppgifter, ring ABAddressBookRequestAccessWithCompletionfunktion efter att ha anropat ABAddressBookCreateWithOptions fungera. De ABAddressBookRequestAccessWithCompletion funktionen blockerar inte appen medan användaren uppmanas att bevilja eller neka åtkomst. Tills åtkomst har beviljats, ABAddressBookRef objektet kommer inte att innehålla några kontakter, och alla försök att ändra kontakter misslyckas med en kABOperationNotPermittedByUserError fel. Användaren uppmanas endast första gången åtkomst begärs; eventuella efterföljande samtal tillABAddressBookCreateWithOptions kommer att använda befintliga behörigheter. Färdigställandehanteraren anropas i en godtycklig kö. Om ABAddressBookRef objekt används i hela appen, då måste all användning skickas till samma kö för att kunna användas ABAddressBookRef på ett trådsäkert sätt.

Kontrollerar åtkomstbehörighetsstatus:

• En app kan använda API:et för auktoriseringsstatus för att kontrollera om den kan komma åt kontakter, kalendrar, påminnelser eller fotobiblioteket. Detta API är oberoende av API:et för begäran om åtkomst och kommer inte att uppmana användaren att bevilja eller neka åtkomst. Med detta API kan en app justera visningen av dess UI-element som skulle komma åt dataklassen. Till exempel, om åtkomst till kontakter är auktoriserad eller inte fastställd, kan en UI-knapp för att välja en kontakt visas.
• För adressbok, ring ABAddressBookGetAuthorizationStatus fungera. För Event Kit, ring authorizationStatusForEntityType: klass metod förEKEventStore. För Assets Library, ring authorizationStatus klass metod för ALAssetsLibrary. Innebörden av statusvärdena som returneras är följande:
  • Auktoriseringsstatus ej fastställd—Användaren har ännu inte gjort något val om huruvida den här appen kan komma åt dataklassen.
  • Auktoriseringsstatus Begränsad—Denna app har inte behörighet att komma åt dataklassen. Användaren kan inte ändra denna apps status, möjligen på grund av aktiva begränsningar som föräldrakontroller.
  • Auktoriseringsstatus nekad— Användaren nekade uttryckligen åtkomst till dataklassen för den här appen.
  • Auktoriseringsstatus Auktoriserad—Denna app har behörighet att komma åt dataklassen.

FAST: I vissa fall kan skärmen visa fel upplösning. Starta om din Apple TV för att återställa den till rätt upplösning.

FAST: Apple TV kan starta om när du använder Remote-appen.

FAST: Apple TV kan starta om när systemspråket ändras.

FAST: Fotoström laddas inte när du loggar in en andra gång. Starta om Apple TV för att lösa problemet.

Musik spelas inte upp under bildspel.

Skärmsläckaren kan återgå till att använda standardbilderna efter installation av uppdateringen. 

Smakämnen NSNetService class och CFNetService API:er inkluderar inte P2P-gränssnitt som standard. För att bläddra, registrera eller lösa tjänster över P2P-gränssnitt måste en app använda Bonjour DNSService*() API:er som anges nedan.

Ställer in parametern interfaceIndex till kDNSServiceInterfaceIndexAny i följande API kommer inte att inkludera P2P-gränssnitt som standard. För att inkludera P2P-gränssnitt måste du nu ställa in kDNSServiceFlagsIncludeP2P flagga vid användning kDNSServiceInterfaceIndexAny eller ställ in interfaceIndex till kDNSServiceInterfaceIndexP2P. De berörda API:erna har:

• DNSServiceBrowse
• DNSServiceRegister
• DNSServiceResolve
• DNSServiceRegisterRecord
• DNSServiceQueryRecord

FAST: Det finns ett känt problem med ordböcker när man försöker definiera ett ord på något annat språk än engelska eller japanska. När referensbiblioteket presenteras får användaren möjlighet att ladda ner en ordbok – den nedladdningen kanske inte börjar. Användaren kan trycka utanför popover-fönstret på en iPad eller trycka på Klar-knappen på iPhone eller iPod touch för att avvisa nedladdningsbegäran.

Begär åtkomst till kalendrar eller påminnelser:

• Användare kan bevilja eller neka åtkomst till händelse- och påminnelsedata per app. För att begära tillgång till händelsen och/eller påminnelsedatumet, ring tillrequestAccessToEntityType:completion:: metod av EKEventStore. Detta kommer inte att blockera appen medan användaren ombeds att bevilja eller neka åtkomst. Tills åtkomst har beviljats ​​för en enhetstyp kommer händelsearkivet inte att innehålla några kalendrar för den entitetstypen och alla försök att spara data kommer att misslyckas.
• Användaren tillfrågas endast första gången åtkomst begärs; eventuella efterföljande instansieringar av EKEventStore kommer att använda befintliga behörigheter. Färdigställandehanteraren anropas i en godtycklig kö.

FAST: När du skapar ett nytt Game Center-konto i appen på iPad, dyker popover för att välja månad för ditt födelsedatum upp utan innehåll att välja.

Smakämnen authenticate metod av GKLocalPlayer har tagits bort. Autentisering startar automatiskt när slutförandehanteraren är inställd.

Från och med iOS 6 beta 4, GKGameCenterViewController singleton stöds inte längre.

Från och med iOS 6 beta 4, GKScore+Sharing.h file och tillhörande kategorier tas bort.

När du skapar ett iCloud-konto kan du använda valfritt e-postbaserat Apple-ID eller ditt befintliga iCloud-konto. Om du hade ett MobileMe-konto som du inte flyttade till iCloud kan du använda det Apple-ID:t för att registrera dig för ett nytt iCloud-konto (ingen av dina tidigare MobileMe-data kommer att finnas). Provisioneringsprofiler måste vara aktiverade för iCloud i iOS Provisionsportal. För att aktivera en provisioneringsprofil för iCloud, navigera till avsnittet App ID i iOS Provisioning Portal och konfigurera ditt App ID för iCloud. När du har aktiverat app-ID för iCloud, återskapa dina provisioneringsprofiler för att aktivera dem för iCloud.

• icloud.com e-postadresser är nu tillgängliga för iCloud-e-postanvändare. Användare som registrerar sig för nya Apple-ID:n eller aktiverar Mail på sitt iCloud-konto för första gången får automatiskt en @icloud.com e-postadress istället för en me.com e-postadress. iCloud-användare med @me.com adresser som har använts med iOS 6 beta 3 eller senare kommer att få en @icloud.com e-postadress som matchar deras @me.com adress.
• icloud.com e-post kan inte skickas från www.icloud.com. Användare bör använda http://beta.icloud.com vid denna tidpunkt om de vill använda en webbläsare för att skicka e-post från sinaicloud.com adress.
• @icloud.com adresser kommer att läggas till inom två veckor efter första användningen av iOS 6.

Smakämnen setSortDescriptors: metod av NSMetadataQuery stöds inte.

I iOS 6 kan filer som är skyddade via dataskydd inte användas med iCloud Storage API:er.

Filnamn är skiftlägesokänsliga i OS X men skiftlägeskänsliga i iOS. Detta kan leda till problem när du använder iCloud för att dela filer mellan de två plattformarna. På iOS bör du vidta åtgärder för att undvika att skapa filer med namn som bara skiljer sig från fall till fall.

Beteendet för samordnade läsoperationer på iCloud-dokument har ändrats:I tidigare iOS-versioner, när din app utförde en koordinerad läsoperation på en fil eller ett paket och iCloud-demonen märkte att det fanns en nyare version av objektet, blockerades den koordinerade läsoperationen tills den nyare versionen av objektet laddades ner och skrivit till skivan.

Från och med iOS 6 beta 3, när du startar en koordinerad läsoperation på en fil eller ett paket som du redan har en lokal version för, kommer den koordinerade läsningen att beviljas så snart som möjligt, och den nya versionen, om någon, kommer att laddas ner i bakgrunden. Detta samtal blockeras endast av nedladdningsskäl om du inte har någon version av filen tillgänglig lokalt.

Dessutom, när filen är i konflikt, kommer iCloud-demonen inte att vänta tills den har alla konfliktförlorare av filen tillgängliga för att göra filen tillgänglig för din app. Det kommer att göra de olika versionerna av den konfliktfyllda filen tillgängliga så snart det kan. Din app kan använda den befintliga filkoordineringen och UIDocument återuppringningar som ska meddelas när konfliktförlorarna har laddats ner och är tillgängliga.

iTunes 10.6.3 krävs för iOS SDK 6.0.

Tidigare offentliga betaversioner av iOS kan inte längre ladda ner iTunes Match-låtar.

I iOS 6 beta 4 infördes ändringar i den nya enumen CLActivityType på kärnplats:

• ersätta CLActivityTypeVehicularNavigation med CLActivityTypeAutomotiveNavigation.
• Lägg till CLActivityTypeOtherNavigation för annan fordonsnavigering – t.ex. båtar, tåg eller flygplan.

I iOS 6 och senare är Map Kit byggt på en ny infrastruktur som är värd för Apple. Tidigare iOS-versioner kommer att fortsätta att använda Googles tjänst. Routingappar som inte anger en täckningsfil under utvecklingen kommer alltid att visas i Maps routings sökresultat.

• API-kompatibilitet kommer att bibehållas (se kända problem nedan).
• Kartor stöds nu i Simulator.
• Kartdata kommer att fortsätta att utvecklas – endast en begränsad mängd högupplösta satellitbilder är för närvarande tillgänglig.

Testning och felsökning av täckningsfiler för routingappar stöds endast under utveckling genom Xcode Run-arbetsflödet. (Du kan ange täckningsfilen för ett givet körschema med hjälp av rutan Alternativ i avsnittet Kör i schemaredigeraren.) Appar som arkiveras och distribueras (utanför App Store) till enheter kommer inte att ha åtkomst till appens täckningsfiler .

FAST: Maps zoomar inte in på den aktuella platsen när den startas från en tredjepartsapp.

FAST: Endast enkla HTTP-nedladdningar fungerar med Newsstand.

Beskrivningsfältet är nu ett obligatoriskt fält för ett Godkänt. Alla pass som skapats utan det kommer inte att valideras och kommer inte att intas.

Passbook i Simulator kräver inte längre https/ssl när du använder a webServiceURL vid intag av ett pass.

FAST: Det går inte att visa boardingkort på låsskärmen.

Pass kommer inte längre att falla tillbaka till background.png if strip.png ingår inte i ditt passpaket.

Innehållet i userInfo ordbok för PKPassLibraryDidChangeNotification har ändrats vid borttagna pass. Se den senaste dokumentationen för den nya userInfo lexikon.

I iOS 5 stöds inte signering av ett certifikat med en MD5-signatur. Se till att certifikat använder signaturalgoritmer baserade på SHA1 eller SHA2.

I iOS 6 finns det förbättrade integritetskontroller för Kalender, Påminnelser, Kontakter och Foton.

• Användare kommer att se åtkomstdialoger när en app försöker komma åt någon av dessa datatyper. Användaren kan slå på och av åtkomst i Inställningar > Sekretess.
• Utvecklare kan ställa in en "syfte"-sträng för varje klass av isolerade data. iOS visar denna sträng för användare för att hjälpa dem att förstå varför deras data efterfrågas. Dessa strängar kan läggas till med hjälp av Xcodes projektredigerare, som finns på fliken Info. De relevanta nyckelnamnen börjar med strängen "Privacy -".
• Det finns ändringar i ramverken för Event Kit och Adressbok för att hjälpa utvecklare med den här funktionen.

FAST: Bekräftelsepanelen för appradering tar ett tag innan den visas i iOS Simulator.

Inga sekretessvarningar visas i iOS Simulator för appar som har åtkomst till foton, kontakter, kalender och påminnelser.

Nedladdning av in-app Purchase-värdinnehåll i iOS Simulator stöds inte.

När du försöker spela upp ett MP3-ljud i Simulator kommer du att höra ett poppande ljud istället.

Användare måste gå till Inställningar > iCloud för att säkerställa att de får meddelanden om delad fotoström.

För att dela en fotoström med iOS 6 beta måste du bjuda in någon som använder hans iCloud-e-postadress; annars kommer han inte att få inbjudan.

Om du uppgraderar från iOS 6 beta 1 till beta 2 kommer din enhet att ladda ner alla dina delade fotoströmmar igen.

Funktionen för delad fotoström är inställd på AV vid uppdatering från iOS 6 beta 1 till en senare version. Standardinställningen ska vara PÅ.

FAST: Om du stänger av delade fotoströmmar kan kameran inte svara; tvångsavsluta kameraappen kommer att lösa problemet.

Weibo visas i appen Inställningar endast om ett kinesiskt tangentbord är aktiverat.

Smakämnen requestAccessToAccountsWithType:withCompletionHandler: metod av ACAccountStore är nu utfasad. För att komma åt användarkonton, användrequestAccessToAccountsWithType:options:completion: metod.I alternativparametern för den här nya metoden, passera nil för att komma åt Twitter- och Weibo-konton. För att komma åt Facebook-konton, skicka en ordbok med följande nycklar (som finns dokumenterade i ACAccountStore.h):

När du begär åtkomst till Facebook-konton är den enda nyckel som krävs i din alternativordbok ACFacebookAppIdKey. ACFacebookPermissionGroupKey ochACFacebookAppVersionKey är nu föråldrad.Om du begär ett skriftligt tillstånd nedan ACFacebookPermissionsKey-Till exempel publish_stream— du måste ge ett värde för ACFacebookAudienceKey, som kan vara en avACFacebookAudienceEveryone, ACFacebookAudienceFriends, eller ACFacebookAudienceOnlyMe.

• ACFacebookAppIdKey
• ACFacebookPermissionsKey

Du bör inte längre lägga till den här ordboken i din app Info.plist fil, som krävdes i beta 1.

Det är nu möjligt att ställa in statusfältets nyansparametrar i din app Info.plist filea. Du kan göra detta för att säkerställa att statusfältets färg matchar din apps navigeringsfältsfärg under uppstart. För att ställa in statusfältets nyans, lägg till UIStatusBarTintParameters nyckeln till din Info.plist filea. Värdet på denna nyckel är en ordbok med lämpliga värden som beskriver navigeringsfältet som din app har vid start. Inuti ordboken ska finnas UINavigationBar nyckel, som har ett värde som också är en ordbok. Den ordboken innehåller den ursprungliga navigeringsfältets stil (med Style nyckel) och om den är genomskinlig (med Translucent nycklar). Om navigeringsfältet använder dem kan du också ange dess nyansfärg (med TintColor nyckel) eller namnet på dess anpassade bakgrundsbild (med BackgroundImage nyckel).

I iOS 5.1 är UISplitViewController klass antar den glidande presentationsstilen när den vänstra vyn presenteras (tidigare bara sett i Mail). Den här stilen används när presentationen initieras antingen av det befintliga barknappsobjektet som tillhandahålls av delegatmetoderna eller genom en svepgest i den högra vyn. Inget ytterligare API-antagande krävs för att erhålla detta beteende, och alla befintliga API:er – inklusive det för UIPopoverController instans som tillhandahålls av delegaten – kommer att fortsätta att fungera som tidigare. Om gesten inte går att stödja i din app, ställ in presentsWithGesture egenskapen för din split view-kontroller till NO inaktiverar gesten. Att inaktivera gesten avråds dock eftersom användningen bevarar en konsekvent användarupplevelse i alla appar.

FAST: I iOS 6 har ändringar införts så att du inte längre behöver ställa in en delegat och implementera en metod för Single-Finger och Single-Tap gestigenkännare. Detta gör att de fungerar bra med UIControl föremål.

I iOS 6 och senare är UIWebView klass målar dess innehåll asynkront.

Autorotation förändras i iOS 6. I iOS 6 är shouldAutorotateToInterfaceOrientation: metod av UIViewController är utfasad. I dess ställe bör du användasupportedInterfaceOrientationsForWindow: och shouldAutorotate metoder.

• Mer ansvar flyttas till appen och appombudet. Nu har iOS-behållare (som t.ex UINavigationController) rådfråga inte sina barn för att avgöra om de ska autorotera. Som standard är en app och en vystyrenhets gränssnittsorientering som stöds inställd på UIInterfaceOrientationMaskAll för iPad idiom ochUIInterfaceOrientationMaskAllButUpsideDown för iPhone idiom.
• En vystyrenhets gränssnittsorientering som stöds kan ändras över tiden – även en apps gränssnittsorientering som stöds kan ändras över tiden. Systemet frågar den översta fullskärmskontrollern (vanligtvis rotvykontrollern) om dess gränssnittsorientering som stöds när enheten roterar eller närhelst en vykontroller presenteras med modal presentationsstil för helskärm. Dessutom hämtas de stödda orienteringarna endast om denna vykontroller återvänder YES från dess shouldAutorotate metod. Systemet skär vystyrenhetens stödda orienteringar med appens stödda orienteringar (som bestäms av Info.plist fil eller delegatens appapplication:supportedInterfaceOrientationsForWindow: metod) för att avgöra om den ska roteras.
• Systemet avgör om en orientering stöds genom att skära värdet som returneras av appens supportedInterfaceOrientationsForWindow: metod med värdet som returneras av supportedInterfaceOrientations metoden för den översta helskärmskontrollenheten.
• Smakämnen setStatusBarOrientation:animated: metoden är inte helt avskaffad. Men nu fungerar det bara om supportedInterfaceOrientations metoden för den översta fullskärmskontrollen återvänder 0. Detta lägger ansvaret för att se till att statusfältets orientering är konsekvent i händerna på den som ringer.
• För kompatibilitet, se kontroller som fortfarande implementerar shouldAutorotateToInterfaceOrientation: metoden får inte de nya autorotationsbeteendena. (Med andra ord faller de inte tillbaka till att använda appen, appombudet eller Info.plist fil för att avgöra vilka orienteringar som stöds.) IställetshouldAutorotateToInterfaceOrientation: metod används för att syntetisera informationen som skulle returneras av supportedInterfaceOrientations metod.

Smakämnen willRotateToInterfaceOrientation:duration:, willAnimateRotationToInterfaceOrientation:duration:och didRotateFromInterfaceOrientation: metoder anropas inte längre på någon vykontroller som gör en helskärmspresentation över sig själv – till exempel genom att anropa presentViewController:animated:completion:.I iOS 6 är viewWillUnload och viewDidUnload metoder för UIViewController är nu utfasad. Om du använde dessa metoder för att släppa data, använddidReceiveMemoryWarning metod istället. Du kan också använda den här metoden för att frigöra referenser till vykontrollantens vy om den inte används. Du måste testa att vyn inte är i ett fönster innan du gör detta.

• Du bör se till att dina appar inte använder dessa metoder för att hantera layouten för några undervyer. Istället bör de använda vykontrollantensviewWillLayoutSubviews metod och justera layouten med hjälp av vyns gränsrektangel.

Det stöds inte att ställa in värden för shadowOffset or shadowColor egenskaper hos en UILabel objekt om dess attributedText egenskapen innehåller en giltig tillskriven sträng. Använd istället NSShadowAttributeName attribut för den tillskrivna strängen för att ställa in skuggan.

På grund av kompatibilitetsproblem, NSBaselineOffsetAttributeName attribut stöds inte längre i iOS 6.

Smakämnen NSTextAlignmentNatural värdet stöds inte och kommer att skapa ett undantag när det används med textAlignment egendom av UILabel eller tillhandahålls som inriktningsparameter till drawInRect:withFont:lineBreakMode:alignment: metod av NSString.

Smakämnen setContentStretch: metod av UIView har fasats ut i denna betaversion. För att uppnå samma effekt, använd resizableImageWithCapInsets: metod av UIImageoch visa bilden med en UIImageView.

Smakämnen resizableImageWithCapInsets: metod av UIImage ändrar effektivt bildernas storlek genom att sida vid sida. Som en prestandaoptimering använder den sträckning snarare än plattsättning när användaren inte skulle kunna se skillnad, till exempel när en enskild kolumn eller rad sträcks ut. Men under vissa omständigheter kanske användaren faktiskt vill sträcka ut en del av en bild. I iOS 6 är resizableImageWithCapInsets:resizingMode: metoden gör det möjligt för den som ringer att ange ett läge för ändring av storleken vid sida eller sträckning.

Smakämnen UICollectionViewLayout klass har ändrats: Den nedre kanten av en UILabel synen skiljer sig nu från dess baslinje.Tidigare tolkade automatisk layout botten av en UILabel vara samma som dess baslinje. Även om det var praktiskt i många fall, orsakade det problem om du ville placera den övre kanten av en etikett mot underkanten av en annan. I ett sådant scenario skulle den nedre etiketten överlappa den översta, och nedstigande etiketter från den översta etiketten kan krascha in i stigare från den nedre etiketten. Nu tolkar automatisk layout UILayoutAttributeBottom som botten av textrutan (förutsatt att etiketten inte är större än dess inneboende innehållsstorlek) ochUILayoutAttributeBaseline som grundlinjen för texten. Om du redan har skapat kod för att lägga ut etiketter enligt botten- eller mittpunkten kommer din text att flytta runt lite och du måste justera dina begränsningar.

• Klassen stöder nu anpassning av animationer som skapas under rotation. Namnen på metoder för att anpassa infoga och ta bort animeringar har också ändrats, så samma krokar kan användas för rotationer såväl som för infogning och borttagning.
• Klassen har ändrat några metodnamn. Specifikt hänvisas inte längre till dekorationsvyer med "återanvändningsidentifierare" utan snarare med "elementtyp". Appar som använder dekorativa vyer måste ändra sin kod och byggas om för att klara detta.

Appar med tabellvyer i sina nib- eller storyboard-filer, och som byggdes med tidigare versioner av iOS 6 beta, kräver en ren konstruktion med beta 3 och nyare.

Här är några anteckningar om stöd för automatisk layout UIScrollView:

• I allmänhet betraktar den automatiska layouten de övre, vänstra, nedre och högra kanterna av en vy som de synlig kanter. Det vill säga, om du fäster en vy till den vänstra kanten av dess översikt, fäster du den verkligen till det lägsta x-värdet för supervyns gränser. Att ändra gränsernas ursprung för tillsynen gör det inte ändra vyns position.
• Smakämnen UIScrollView klass rullar dess innehåll genom att ändra ursprunget för dess gränser. För att få detta att fungera med automatisk layout, innebörden av de övre, vänstra, nedre och högra kanternainom en rullningsvy betyder nu kanterna på dess innehållsvy.
• Begränsningarna på undervyerna i rullningsvyn måste resultera i en storlek att fylla, som sedan tolkas som innehållsstorleken i rullningsvyn. (Detta ska inte förväxlas med intrinsicContentSize metod som används för automatisk layout.) För att ändra storlek på rullvyns frame med automatisk layout måste begränsningar antingen vara tydliga vad gäller bredden och höjden på rullningsvyn, eller så måste kanterna på rullningsvyn vara knutna till vyer utanför av dess underträd.
• Observera att du kan få en undervy av rullningsvyn att verka flytande (inte rulla) över det andra rullande innehållet genom att skapa begränsningar mellan vyn och en vy utanför rullvyns underträd, till exempel rullvyns översikt.
• Här är några exempel på hur du konfigurerar rullningsvyn:
  • Blandat tillvägagångssätt:
    1. Placera och storleksanpassa din rullningsvy med begränsningar utanför rullningsvyn – det vill säga translatesAutoresizingMaskIntoConstraints fastigheten är inställd på NO.
    2. Skapa en slätt UIView innehållsvy för din rullningsvy som får den storlek du vill att ditt innehåll ska ha. Gör den till en undervy av rullningsvyn men låt den fortsätta att översätta masken för automatisk storleksändring till begränsningar:

       UIView *contentView = [[UIView alloc]

       initWithFrame:CGRectMake(0,0,contentWidth,contentHeight)];

       [scrollView addSubview:contentView];

       // Ändra INTE contentView's translatesAutoresizingMaskIntoConstraints,

       // som är standard till YES;

    3. Ställ in innehållsstorleken för rullningsvyn så att den matchar storleken på innehållsvyn:

       [scrollView setContentSize:CGMakeSize(contentWidth,contentHeight)];

    4. Skapa vyerna du vill lägga in i innehållsvyn och konfigurera deras begränsningar så att de placeras i innehållsvyn. Alternativt kan du skapa ett vyunderträd för att gå i rullningsvyn, ställa in dina begränsningar och anropa systemLayoutSizeFittingSize: metoden (medUILayoutFittingCompressedSize alternativ) för att hitta den storlek du vill använda för din innehållsvy och contentSize egenskapen för rullningsvyn.
  • Ren autolayoutmetod:
    1. I det här fallet, translatesAutoresizingMaskIntoConstraints måste ställas in på NO på alla inblandade synpunkter.
    2. Placera och ändra storlek på din rullningsvy med begränsningar utanför rullningsvyn.
    3. Använd begränsningar för att lägga ut undervyerna i rullningsvyn, se till att begränsningarna knyter an till alla fyra kanterna av rullningsvyn och inte lita på rullningsvyn för att få deras storlek. Ett enkelt exempel skulle vara en stor bildvy, som har en inneboende innehållsstorlek härledd från bildens storlek. I den viewDidLoad metod för din vykontroller, skulle du inkludera kod som följande:

       UIScrollView *scrollView = [[UIScrollView alloc] init];

       UIImageView *imageView = [[UIImageView alloc] init];

       [imageView setImage:[UIImage imageNamed:"MyReallyBigImage"]];

       [self.view addSubview:scrollView];

       [scrollView addSubview:imageView];

       scrollView.translatesAutoresizingMaskIntoConstraints = NEJ;

       imageView.translatesAutoresizingMaskIntoConstraints = NEJ;

       NDictionary *viewsDictionary = NDictionaryOfVariableBindings(scrollView, imageView);

       [self.view addConstraints:[NSLayoutConstraint constraintsWithVisualFormat:@"H:|[scrollView]|" optioner:0 mätvärden: 0 visningarDictionary:viewsDictionary]];

       [self.view addConstraints:[NSLayoutConstraint constraintsWithVisualFormat:@"V:|[scrollView]|" optioner:0 mätvärden: 0 visningarDictionary:viewsDictionary]];

       [scrollView addConstraints:[NSLayoutConstraint constraintsWithVisualFormat:@"H:|[imageView]|" optioner:0 mätvärden: 0 visningarDictionary:viewsDictionary]];

       [scrollView addConstraints:[NSLayoutConstraint constraintsWithVisualFormat:@"V:|[imageView]|" optioner:0 mätvärden: 0 visningarDictionary:viewsDictionary]];

       Detta skulle ge dig en rullningsvy som ändrats till vykontrollantens vy (som vid enhetsrotation), och bildvyn skulle vara en rullande undervy. Du behöver inte ställa in innehållsstorleken för rullningsvyn.

Med tanke på denna vyhierarki:

ContainerView

| OddHeightView

| | EvenHeightView

| OtherFixedHeightView

och dessa begränsningar:

EvenHeightView.centerY == OddHeightView.centerY

EvenHeightView.bottom (eller baslinje) == OtherFixedHeightView.bottom (eller baslinje)

OtherFixedHeightView.top == ContainerView.top +

i iOS 6 beta 4, på icke-Retina-skärmar, botten (eller baslinjer) av EvenHeightView och OtherFixedHeightView var avstängd med en pixel och utvecklaren kunde inte göra något åt ​​det. Det här problemet är nu åtgärdat.

I iOS 6 beta 4 finns det ett känt fel att när du har en begränsning med ett objekt som är en rullningsvy, är det andra objektet en avkomling av den rullningsvyn, och du lägger till begränsningen till en förfader till den rullningsvyn, då kan begränsningen sluta fungera korrekt. Lösningen är att lägga till sådana begränsningar endast till själva rullningsvyn, inte till någon gammal förfader.

• Före ändringarna integrerade layoutmotorn inte positionsvariablerna för vyerna, och dessa begränsningar var alltid tillfredsställande:

  ContainerView

  | OddWidthView

  | EvenWidthView

  OddWidthView.centerX == ContainerView.centerX

  EvenWidthView.centerX == ContainerView.centerX

  EvenWidthView.centerX == OddWidthView.centerX

  Nu integrerar layoutmotorn positionsvariablerna (x och y) såväl som dimensionsvariabler (bredd och höjd). Detta betyder att den kommer att försöka uppfylla de tre begränsningarna med en heltal lösning, vilket kanske inte är möjligt, och därmed loggar att dessa begränsningar är otillfredsställande. I det här fallet, och i alla analoga fall, behöver utvecklare bara ta bort den redundanta begränsningen (eller begränsningarna). I exemplet ovan löser du problemet om du tar bort någon av de tre begränsningarna.

WebKit på iOS stöder nu requestAnimationFrame och cancelAnimationFrame metoder i JavaScript, som beskrivs här: http://www.w3.org/TR/animation-timing/.Standardkvoten för app-cache har ökat från 5 MB till 25 MB.

• Observera att eftersom specifikationen fortfarande är i Working Draft-tillståndet har dessa metoder webkit prefix, så de har window.webkitRequestAnimationFrame ochwindow.webkitCancelAnimationFrame.

JPEG-subsamplingströskeln har ökat från 2 MP (megapixel) till 5 MP på all hårdvara som stöds förutom iPhone 3GS och iPod touch (4:e generationen).

Support har lagts till för <input type="file"> taggar i webbformulär. Användare kan ladda upp befintliga foton och videor från sitt fotobibliotek eller ta en bild eller video med kameran. Tidigare var den här formulärkontrollen alltid inaktiverad.

Med Safari 6.0 på OS X kan utvecklare nu använda Web Inspector (webbutvecklingsverktyg) med anslutna iOS-enheter och iOS Simulator. Utvecklare kan använda webbinspektören för att felsöka Safari och UIWebView klass i sina egna appar byggda och körs från Xcode. Detta ersätter Debug Console-bannern i Safari.

I iOS 6 och senare, webbdata (SQL Web Storage och LocalStorage) från en UIWebView objekt kan lagras i en katalog som kommer att säkerhetskopieras. För att möjliggöra säkerhetskopiering av denna data, ställ inWebKitStoreWebDataForBackup nyckel till YES i appens användarstandarder. Detta bör endast göras om din app förlitar sig på webbinnehållsdata som inte kan laddas om. Om dinUIWebView objekt öppnar länkar till godtyckligt webbinnehåll, denna nyckel ska vara inställd på NO. Att växla värdet på denna nyckel kommer inte att bevara befintlig webbvydata.

I iOS 6 och senare registrerar Safari inte längre för det vanliga feed: RSS/ATOM-scheman. Appar som kan se dessa typer av flöden uppmuntras att registrera sig för det URL-schemat.

WebKit skapar inte längre alltid hårdvaruaccelererade lager för element med -webkit-transform: preserve-3d frivillig. Författare bör sluta använda det här alternativet som ett sätt att få hårdvaruacceleration.

Experimentellt stöd för CSS3 Flexbox kommer att inaktiveras. Vänligen byt från att använda -webkit-flexbox och -webkit-inline-flexbox till -webkit-box och -webkit-inline-box.

Från och med iOS 6, inbäddade YouTube-webbadresser i form av http://www.youtube.com/watch?v=oHg5SJYRHA0 kommer inte att fungera längre. Dessa webbadresser är till för att titta på videon på YouTubes webbplats, inte för att bädda in på webbsidor. Istället beskrivs formatet som ska användas här: https://developers.google.com/youtube/player_parameters.

I iOS 6 är keyboardDisplayRequiresUserAction egendom lades till UIWebView klass. Egenskapen har som standard YES, vilket betyder att ringa focus() på ett formulärelement kommer inte att visa tangentbordet. Genom att ändra fastigheten till NO, ett JavaScript-anrop till focus() på ett formulärelement fokuserar elementet och tar fram tangentbordet automatiskt.

Från och med iOS 6, ringer focus() på ett formulärelement i en webbapp fokuserar elementet.