WWDC 2020

• Apps and Widgets
  • Complete app using SwiftUI
  • body can return a scene (vs only some View before)
    • WindowGroup for multiple windows (macOS and iPad)
    • Settings
    • DocumentGroup
  • .commands modifier adds custom menus and keyboard shortcuts.
  • Multiplatform templates in Xcode
  • Launch screen info.plist key to configure launch screen (instead of storyboard)
• Lists and Collections
  • Provide a children key path to add outlines to lists.
  • LazyVGrid and LazyHGrid (collection views?)
  • LazyVStack and LazyHStack
• Toolbars and Controls
  • .toolbar modifier
  • Labels can include icon (will decide when to show text, for example will not show text in toolbar)
  • .help modifier to tooltips on macOS (a11y for a11y on iOS)
  • ProgressView (spinner, progress bar)
  • Gauge
• New effects on styling
  • .matchedGeometryEffect for better transitions
  • ContainerRelativeShape() to match modifier to parent.
  • System accent color (in asset catalog)
• System integration
  • Link to URLs or other apps

• Concepts (CoreData / CloudKit)
  • Objects - NSManagedObject / CKRecord
  • Models - NSManagedObjectModel / Schema
  • Stores 0 NSPersistentStore / CKRecordZone or CKDatabase
• recordName and modifiedAt need to be added in CloudKit dashboard for public databases.
• Good example for a public database would be a high score table.
• Public database does not support push notifications, uses polling.
  • Polling only happens on launch or after 30 minutes, data is not always up to date.
• Read/write access
  • For private databases, read/write/modify only when signed in.
  • For public databases, read available when not signed in, but write and modify need user to be signed in (some exceptions with modify)
• canUpdateRecord used to check if records can be modified
• canDeleteRecord will return false if record is stored in public database (changes won’t be propagated to other devices) - use something like isTrashed property on object.

• What to think about when creating a new SwiftUI view
  1. What data does this view need to do its job?
  2. How will the view manipulate that data?
  3. Where will the data come from? (SoT)
• Passed object to subview as a regular property, but because it’s a value type, would make a copy.
  • @State would create a new SoT.
  • @Binding is correct way (to be able to write from subview)
  • $ needs to be used to pass the binding type.
• ObservableObject
  • objectWillChange is the only required method.
  • New SoT
  • One for entire app, or broken up
  • Add @Published to properties that might change (how does this work for CoreData?)
  • All views that use @ObservedObject will be notified on objectWillChange (will change so SwiftUI can collapse all changes).
• @StateObject (new in iOS 14) - SwiftUI owns the ObservableObject and is run just before body is called.
• @EnvironmentObject allows you to use an object in a deep down subview without a lot of boilerplate (i.e. passing it down through each view)
• Slow updates
  • Make view initialization cheap
  • Make body a pure function
• New updates for data persistence in iOS 14.

• In Xcode 12, select “multiplatform” setting when creating a new project. (iPhone, iPad, macOS).
• Add new views from canvas (preview window) or directly in code (no more storyboards).
• Cmd-click to add modifiers (either in canvas or code).
• List data items need to conform to Identifiable.
• Use an extension on the model to provide test data (for preview mode).
• Cmd-click and “extract code” to extract views into their own subviews.
• Pass data model to List() if entire list is data driven, but use ForEach() to add other items to the list (like a footer).
• Image modifiers like contentMode show instantly in preview!
• View is nothing but a struct
  • Doesn’t inherit any stored properties.
  • Allocated on stack.
  • Passed by value.
  • No additional allocation or reference counting for properties.
  • SwiftUI collapses view hierarchy, so make liberal use of small single purpose views.
  • Views are incredibly lightweight, extracting subview no runtime overhead.
  • Only requires body property.
  • Set breakpoint in body to see when framework decides it needs a refreshed view.
• @State
  • Allocates persistent storage for variable on view’s behalf.
  • Every time state variable is written view will re-render.
  • State variables and model constitute the SoT for entire app.
  • @Binding is read-write derived value (use for views that don’t own the object).
• Graph showing cure of bugs compared to mental overhead at ~28:30
• withAnimation to animate a property change.
• @StateObject for a class that acts as a store.
• @ObservedObject is an object that is passed into a view that needs to be observed.
• .environment way to set contextual information that flows down the view hierarchy (note that .environment/@Environment is used for key paths which already exist and .environmentObject/@EnvironmentObject for custom objects/properties).

• Ability to download HLS introduced in 2016.
• Use when user indicates they want to download media.
• How to get started?
  1. Create a download task
  2. Monitor the download task
  3. Play the downloaded content
• Download task
  • Inherits features of URLSession
  • Automatic media selection (current device locale downloads that language/subtitles)
  • Delegate method returns progress (around 4mins)
  • AVAggregateAssetDownloadTask allows you to set preference for which audio and subtitle renditions to download.
  • Download tasks will continue when app is backgrounded, get download task using URLSessionConfiguration and identifier used when setting up task.
• Playing a download
  • Location is returned when download is complete.
  • Reuse asset for playback so it will play before download is finished.
• Offline key to be used when you want to only allow content to be played offline for a certain amount of time (e.g. movie rental)
• Fast download vs high quality - allow the user to choose.
  • iOS 14 allows for presentation size as well.
• Storage management
  • Do not move, be prepared for assets to be deleted by system.
  • Allowing system to hander allows user to delete (shows up in storage settings).

1. Video materials
   • Glow effect
   • Instructional videos (map video to a plane)
   • Video play spatialized audio (acts as if the sound source is from a specific location)
   • Uses AVFoundation/AVPLayer passed as a material.
2. Scene understanding using LiDAR
   • Occlusion (hides behind real world objects)
   • Receives lighting (add shadows on real world surfaces)
   • Physics
   • Collision
   • Summary of scene understanding:
     • Goal: make content interact with real world.
     • Occlusion and shadows improve realism.
     • Physica and collision against real world meshes.
     • Scene understanding entity created and managed by RealityKit.
3. Improved rendering debugging
4. Face tracking (ARKit 4)
5. Location anchors (ARKit 4)

Ok, so not a lot of information, but it is a short video. Specific to using media intents (audio) on Apple TV and HomePod. Basically media intents run on those platforms now, and there’s one new feature, alternative results.

• Apple TV
  • “Play music on your app”
  • Same way you implement on iOS (via intent extension)
  • Guess this works for HomePod, too? (they didn’t really say)
• New Features
  • Alternative options - “maybe you wanted” surfaces options user may have wanted by implementing successes(resolvedMediaItems:_) (plural version of what you would implement before)
• App prewarming can launch app sooner to do things like fetching data such as authentication details earlier (need to “work with Apple” to get this working, not sure what that means).

Honestly, I had never even looked at the Xcode Organizer (window menu in Xcode), so learned that this exists! Short video about some of the changes in Xcode 12, mainly UI refresh and 2 new metrics.

• App analytics sent back via organizer window
• Xcode 11: battery usage, launch time, hang rate, memory usage, disk writes
• New metrics:
  • Scroll hitches
    • Hitch time (ms) / scroll duration (s) = hitch rate
      • < 5 ms/s - smooth
      • 5-10 ms/s - uh oh

      • 10 ms/s - dropped frames

  • Disk write diagnostics
    • Reduce amt of writes: better perf and battery life
• Second half of video was demoing some of these new features and new UI.

Overview of how to get started with HealthKit. Very basic, but great if you’ve never done anything with HealthKit before (like me!)

• Why use HealthKit?
  • Central repository for all health data developers can read and write to.
  • Takes care of syncing between devices.
  • Advanced queries to pull exact data you need.
• Setup
  • Give application access.
  • Check platform availability.
  • HKHealthStore - entry point to HealthKit API (one instance used throughout application).
• Authorization
  • Allow data by type (don’t request all types, over 100!)
  • Broken down to read and write
  • Only ask what you need, when you need it, every time you need it (in case permissions have changed).
• Hierarchy of data objects
  • HKObject (parent type which includes things like device that recorded it, unique identifier for data, application that wrote it).
    • HKSample
      • HKQuantitySample - used for any quantity types (walking with miles, hearing with db level)
      • HKCategorySample - list of values, no unit (an event like brushing teeth)
      • HKWorkout - multiple values
      • And others…
    • HKCharacteristic - static stuff like birthday, blood type.
  • Similar hierarchical chain for HKObjectType
• HKStatisticsQuery - get data based on certain conditions
  • Deduplicates data (iPhone and watch)
  • Collection type also available to get daily/weekly/monthly values.
  • Update handler to monitor changes to health data (use case: add steps to health data, update table view when data changes)
• HKSampleQuery for retrieving other data.
  • Also: HKAnchoredObjectQuery, HKActivitySummaryQuery (activity rings), HKWorkoutRouteQuery

• Workflow: source material -> media encoder -> segmenter -> web server
• AVAssetWriter - outputs media in fragmented MP4 format.
• Either source file or capture (live) video to fragmented files via AVAssetWriter.
• Format structure
  • MP4: file type, movie, media data
  • Fragmented movie (fMP4): file type, media data, movie, media data, movie fragment, media data, movie fragment,…
• Code example of how to configure AVAssetWriter (~5:30).
• Lots of detailed examples throughout rest of session.

• Xcode 12 Swift 5.3
• Runtime
  • Code size smaller (Swift 4 2.3x Objc version, 5.3 down to 1.5x)
  • SwiftUI app 43% reduction (Xcode 11 to Xcode 12)
  • See ~4:00 for interesting memory layout example, why value types are more performant.
  • Heap usage overhead uses a third of what it did.
  • Sits below foundation framework, can be used where previously C has to be used.
• Improvements to diagnostics and code completion (speed and accuracy)
• Increased robustness in debugging (lldb)
• Official support for windows
• New language features
  • Multiple trailing closure closure syntax (SE-0279)
  • KeyPath expressions as functions (SE-0249)
  • @main (SE-0281)
  • Increased availability of implicit self in closures (SE-0269) - including self in capture list doesn’t mean you need it in the body or if struct can remove it.
  • Multi-pattern catch clauses (SE-0276)
  • Enum enhancements
  • Embedded DSL enhancements
  • And more…

Not a lot of tactile information on symbols, but a lot of recap and lots of information for how to use for designers.

• Symbols provide consistent experience and work well with default font (San Francisco).
• Some symbols match baseline, some do not - intended to balance San Francisco.
• SF Symbols app (designer can use to paste into Sketch)
• Usage: UIImage(systemName:)
• Symbols match text styles for dynamic text sizing.
• All platforms support SF Symbols (new for macOS)
• Additions and refinements
  • 750 new - devices, transportation, game controllers, human related symbols
• Localized automatically (even for RTL)
• Multiple colors (like weather app)

• Shortcuts app (on watch)
  • Choose which shortcuts to sync to watch.
  • Complications to launch specific shortcuts.
• Recap how you can offer shortcuts
  • SiriKit and NSUserActivity
• If using NSUserActivity, app needs to open on device, will not work on watch because it’s a jarring experience to open an app on a different device.
• Intents is the way to go, but…
  • IntentsUI does not work on watch
  • Best option is to have a watch app if user needs to do something in app
  • If no watch app, run via extension (creating a separate target for watch intent)
  • Final option, remote execution. Slower. Needs to run completely in background (.continueInApp cannot be used, need to support background execution).

So much exciting stuff I didn’t know about from the keynote!

• SiriKit
  • Disambiguation - follow up questions
    • New API to customize how list is displayed (subtitles and images)
  • Intents UI - how your app shows up in Siri
    • Compact UI - show what’s important
    • Vertical height should be considered
    • Consistent background material (color, material, vibrancy) - keep views transparent
• Shortcuts
  • Folders for shortcuts!
  • Apple Watch has a shortcuts app!
  • Complications can be a shortcut.
  • Cool automation idea - when journal app is opened -> DND, Streaks app, playlist.
  • New triggers - receive email or message, close an app, battery level, connect to charger.
  • Automatic running for time of day!
  • Automation suggestions to gallery.
  • Mindfulness, journaling, music - app can be featured in the wind down experience (INShortcutAvailabilityOptions)

Session is specific to Playgrounds in Xcode (not standalone macOS, iOS app). Pretty interesting, nonetheless. I love the idea of being able to include a Playground with your package for documentation and tutorials!

The second half of the video was interesting. He demo’d CoreML and vision framework to identify fruit all within Playgrounds. This might also work on iOS and macOS app? 🤔

• Playgrounds work in packages making a great way to demo and document
• Frameworks and packages can be used in Playgrounds as long as they’re in the same workspace (use “build active scheme” in playground)
• Build logs for Playgrounds available under build tab.
• Access to images from asset catalog (drag into playground)

• In iOS 14, collections are split into three main areas: Data (diffable data source), layout (collection view layout), presentation (configurations and configuration states, this session!)
• Configurations
  • defaultContentConiguration always returns a fresh configuration.
    • Configurations are lightweight (value types).
    • Default configuration means you don’t have to deal with the old state!
    • Default styling based on cell and context (table view/collection view).
    • Properties are not specific to views (text/image vs label/imageVIew) - configurations can now be used on any view that supports them.
  • Set configuration with contentConfiguration property.
  • Background configuration for bg color, visual effect, stroke, insets, custom view.
  • Content configuration for content, e.g. image, text, secondary text, layout metrics and behaviors.
• Configuration states
  • Traits (size class, content size category, layout direction, misc states, custom states)
  • Custom state is like having a view model for each cell
  • Each cell, header, footer has its own configuration state.
  • Different class for cells and views - cell configuration state adds things like editing, swipeable, etc.)
  • configuration.updated(for: state) to update the state (original configuration with new state)
  • Disable automatic updates to manually update configurations (in addition to state)
  • Override updateConfiguration: to update configurations and any other cell properties before displayed (gives you the state so you can update cell based on current state properties)
• Color Transformer - function that returns a modified output color for an input color.
• Default configurations available for list cells, sidebar cells, etc.
• Configurations work with custom views, too. Use as an object to hold default values since object is so light.

Not a lot of useful information in this video other than to introduce the idea of putting custom views into the Xcode library. It’s a fun watch!

• Since the very beginning, Xcode Previews was built to put your content front and center.
• For example, your views are previewable without doing any extra work, and most views and modifiers are inspectable right out of the box as well.
• In Xcode 12, we are taking a step further by letting you add your SwiftUI views and modifiers to the Xcode library.

Overview of all the new additions to collection views as far as lists (think UITableView). There’s lots of neat improvements including self sizing cells being default and just generally more dynamic and flexible with sizing.

• UITableView-like appearance
• Optimized self sizing
  • preferredLayoutAttributes: on cell subclasses if you still need set height/width
• Built on top of compositional layout.
• Return different layout configuration for each section using NSCollectionLayoutSection.
• firstItemInSection can be set by config so first item is the header (data must be aware because now first item is header)
• Swipe actions are now a feature of the cell (in a list cell)
• Separators - separator layout guide to change where separator is positioned (aligned with text, for instance)
• New accessory types, both for trailing and leading
  • Reorder accessory view automatically sets up collection view to reorder.
  • Outline disclosure to automatically create outline view (using new section snapshot APIs).

Good overview of all the new stuff for UICollectionView this year. New stuff for diffable data source, lists (collection view looks like a table view!), and cell configurations.

• Since the beginning, collection view APIs have separated concerns:
  • Data - UICollectionViewDataSource
  • Layout - UICollectionViewLayout
  • Presentation - cell, reusable cells
• New last year
  • Data - diffable data source
  • Layout - Compositional layout
• New this year
  • Data - section snapshots
  • Layout - list configuration
  • Presentation - list cell, view configuration
• Overview of the new stuff this year:
  • Section snapshots - encapsulate the data for a single section in a UICollectionView
    • More composable into section size chunks of data.
    • Modeling of hierarchical data.
  • Lists
    • UITableView like appearance
    • Swipe actions, cell layouts
  • Cell registrations are a new API to configure cells (no need for reuse identifier)
  • Cell content configurations to easily get a default configuration (value cell, subtitle cell, etc.)

This session is all about creating an entire SwiftUI app using nothing but SwiftUI. Even thought I’m not really doing a lot of SwiftUI, interesting to see how they talk about the hierarchy between App, Scenes, View. Also this app is only a few lines of code (entire app!) and works on macOS, iOS, and watchOS!

• Hierarchy is App -> Scenes -> Views
• Scenes
  • Most common is a window.
  • Could be tabs, too.
  • Parent scene could hold several scenes (tabs).
  • Views contain the content of the scene.
• Scene defined with WindowGroup (there is also DocumentGroup for document based apps, they talk a little about this at the end of the video).
• @main attribute designates a struct as the main start point for an app (no longer need a main.swift file).
• Navigation title used to populate a title in app switcher (or expose on iPad).
• Merge into single window (into tabs) comes for free!
• All scenes have their own state.

I was hoping I could get a feel for what it’s like to develop on tvOS, but not really. Just talks about some of the new SwiftUI goodness and how it can be applied to a tvOS app.

• CardButtonStyle for buttons that move around with remote (like all of Apple’s stuff)
  • Usage: .buttonStyle(CardButtonStyle())
• Context Menus now easy to implement
  • Usage: contextMenu{} modifier.
• Focus improvements
  • New isFocused environment variable.
• tvOS will geometrically determine what view should be focused (normally top left focusable element).
• Unrelated to tvOS (I think) is @Namespace modifier to provide a unique id (used in example to change an environment variable in just one view.
• Lazy Grids are a new SwiftUI thing and can be used to create a row of playlists in their example.

Almost didn’t watch because they started out saying it was more of an advanced course on background execution, but not really. Great overview of the different background modes and how the system prioritizes tasks based on a number of factors.

• Your app has its own concerns (stay updated, etc.), but that needs to be balanced with system concerns, including:
  • All-day battery
  • Performance
  • Privacy
  • Respecting user intent
• Factors considered when choosing whether or not your app can run:
  • Critically low battery
    • Below 20%, essential work only
  • Low power mode
    • Different from above because it’s user indicated.
    • Could be more restrictive, but app can access/be notified if it’s enabled.
  • App usage
    • Apps user uses the most, at the current time of day.
  • App switcher
    • Constraints to apps still visible in the switcher. Pretty much applies to all background tasks (if user closes app from app switcher).
  • Background app refresh switch
    • Defaults to on.
    • Notification when user enables/disables.
  • System budgets
    • Energy and data budget, distributed throughout the day.
    • Developer can tip this by:
      • Hardware intensive resourcess (GPS and acceleomater)
      • Using cellular data
  • Rate limiting
    • System reasonably spaces out launches depending on what’s appropriate.
• Specific background modes
  1. Background app refresh tasks - run app periodically in the background so app is fresh when user launches (social media feed, stock price, etc.)
  2. Background pushes - alerts the application not the user (low priority like muted messages, emails, etc.)
     • Factors: Everything except for app usage
     • Rate limiting does apply. Delays the delivery of some pushes while maintaining a frequent launch pushes (so don’t depend on getting a silent push each time).
  3. Background URL sessions - downloads or uploads that are transferred to the system (file uploads, photo uploads, social media feed content)
     • Config option to prevent transfer from using cellular - use it!
     • sessionSendsLaunchEvents requests the system launch app after background transfer is complete.
     • isDiscretionary allows transfers to be deferred (when phone is plugged in, etc.)
     • When starting a task from background the system will ignore isDiscretionary and treat as true (only works on foreground)
     • Rate limiting and app usage do not apply to non discretionary transfers (except for launch event upon completion).
     • Discretionary transfers are only stopped by app switcher and some system budgets (doesn’t even follow app refresh switch)
  4. Background processing task - tasks that take several minutes when user not accessing device while plugged in (CoreML training!)

Nice overview of using Playgrounds on iPad. Also a nice overview of creating a simple SwiftUI view.

• When starting a new project, choose “Xcode Playground” (vs a Playground book). Woah, mind blown, didn’t know this existed. Although I’m not entirely sure what the actual difference between the two are.
• Move curly brace around existing code by dragging it down.
• Locations button on top left to get playgrounds saved in other places.
• Color picker in autocomplete bar to find a UIColor.
• Move code to new file under Shared Sources, like moving to a new target.
• Lots of keyboard shortcuts highlighted in this session!

Not a lot of in depth information on creating a Playgrounds book, just comparing the differences between Mac and iPad. Second half of the session is a demo where a button is conditionally shown on iPad for an ARKit experience (cool that you can do ARKit in Playgrounds!).

• Differences between platforms (Mac and iPad):
  • Code completion includes quick help on Mac and presented in a popover like view.
  • Designate which device the book is supported with key in manifest (iPad or Mac).
  • UIRequiredDeviceCapabilites to target capabilities (ARKit, Microphone, WiFi).
  • Use generic words like tap or select (instead of click or touch) in documentation/comments.
  • Use target checks for conditionals (similar to in app code).

Not really applicable unless you have a Yelp-like app, but interesting to learn about how App Clips are all separate apps from the user perspective, but all just open your app. Developer is responsible for handling different “skins” of the app for each business.

• Who is this good for?
  • If your app aggregates many businesses in to a customer-facing app (Yelp!)
  • If your app is a rewards program.
• Entry point for App Clips: Messages, smart app banner, NFC/QR, location based suggestions.
• targetContentIndentifier in user defaults should be used to send notification to the correct app clip experience (all separate apps)
• Developer should save state in case user opens another app (still your app, but different content identifier) but then wants to go back to original app.
• App clip card designed in App Store Connect.
• Each app clip gets it own icon which comes from Maps (what happens for businesses that aren’t location based?)
• Access App Clips via recently added, spotlight, proactive suggestions, messages, maps and safari

• If you use Photos picker, no more permissions prompting!
• PHPickerViewController gets config when initialized (images vs video, etc.)
• Delegate lets you know when photo or video is picked.
• PhotoKit might still be necessary when:
  • Non-destructive image editing
  • Photos library organization
• PhotoKit can be used with Photos picker. Photos picker can just serve as the UI so you don’t have to create your own and it’s more consistent with the rest of iOS (PHPickerViewController).
• Also new: Limited photos library. User can now select photos to be accessed.
• AssetsLibrary is deprecated, use PhotoKit (or even better, new Photos picker if you don’t need the extra stuff).

• “Widgets are not mini apps”
• Siri shortcuts donations for smart stack.
• WidgetKitAPI to help decide when your widget is most relevant.
• 3 sizes (.systemSmall, .systemMedium, .systemLarge).
• Configuration options are built using intents framework.
• Inspiration from Watch complications.
• Setup
  • StaticConfiguration (activity) vs IntentConfiguration (reminders)
  • Placeholder UI is provided during initialization, placeholder interface when nothing available.
• Small single tap target, medium/large can have multiple tap targets.
• Views
  • Placeholder - before any content
  • Snapshot - first entry, quick to load
  • Timeline - series of subsequent views (combination of view and date)
    • Return 1 days worth of content
    • Reloads are where the system will wake up your extension
• ReloadPolicy - at end, after a date, never
  • Widgets viewed frequently will receive more reloads.
• Updates from timeline can occur by:
  • Background notification
  • App itself (when opened by user)
  • Background URLSession

• UISlider - small UI tweaks, matches macOS more.
• UIActivityIndicatorView - small UI changes, simpler looking.
• UIPickerView - minor changes, preference is to use UIMenu if it makes sense (see below).
• UIPageControl - small UI tweaks and allows unlimited pages.
• UIColorPickerViewController presented as a sheet or popover
  • Picking from a grid
  • Spectrum graident
  • RGB or hex codes
  • Eyedropper
• UIDatePicker - new calendar UI, compact or full options. No more for date/month/year!
• Menus (UIMenu)
  • UIButton and UIBarButton now have a menu property to easily add a menu.
  • showsMenuAsPrimaryAction causes the button to show immediately on touch.
  • UIDeferredMenuElement for dynamic menus
• Actions (UIAction)
  • No longer need to use target action.
  • Easier to share tap actions.

• Existing
  • People
  • Face detection
  • Face landmarks
  • Human torso detection
• Hand pose (new)
  • What can be done?
    • UI control to take a selfie
    • Map emojis to hand movements
  • Four landmarks for each finger, 1 for the wrist
  • Demo: app to draw line on screen when tip of index finger and thumb are together
• Human body pose (new)
  • What can be done?
    • Apex of a jump
    • Work and safety poses for training
    • Fitness app for jumping jacks
• What’s the difference between ARKit and Vision?
  • ARKit - newer, but fewer devices.
  • ARKit requires an AR session, so good for showing live on screen.
  • Vision framework is good for reading captured images.
  • Vision framework has more support, also can be used on macOS.
  • Seems like the preference is to go with ARKit when possible?

• Location anchors
  • Take ARKit outside!
  • Geo-referenced AR content (latitude and longitude).
  • Apple Maps visualizations used to place objects.
• Scene geometry
  • LiDAR shoots light onto subject, depth measured by time it took light to hit subject and returned.
  • Topological map of the environment.
• Depth
  • Heat map to show distance of objects, depth of room.
• Object placement
  • Easier and more accurate to place objects.
• Face tracking
  • Extended to devices without a TrueDepth camera (as long as A12).

• Create second application target, contains all code and assets to handle app clip experiences.
• Requires an app as well, needs to be submitted together.
• Make as small as possible (must be less than 10mb after thinning).
• Reorganize app into user flows to better use app clips (so a user can pick up where he/she left off in the app clip)
• Cannot access to all personal data (like health kit), but use checks as normal to see if data is available.
• Access to all iOS frameworks.
• App clips not included in iOS backups and will be deleted after inactivity.
• Cannot register for universal links or URL schemes.
• App clips can store data, but treat as temporary cache because app clip can be removed after inactivity.
• Automatically migrate authorizations for camera, microphone, bluetooth access to main app (if installed).
• Data can be stored in a shared data container (not default) and full app can pull from it.
• SKOverlay to be lead to full app (new).

• Apple Silicon vs Intel
  • Universal app compiles for both Intel and Silicon (2 slices in the same binary, resources are the same). Same as 32bit and 64bit apps.
  • All iOS apps will run on Apple Silicon devices automatically.
  • Use catalyst to adapt for Mac (and to run on intel macs).
• iPad
  • Sidebars
  • Context menus
  • Color picker
• Lidar
  • Use ARKit API
  • Measures distance to objects making experience more realistic (objects can be placed behind real world objects)
• Widgets
  • SwiftUI
  • Define what widgets look like via SwiftUI
  • Data changes via a scheduled timeline so app doesn’t have to run
• App Clips
  • 10mb max
  • Notifications for 8 hours
  • Downloads while bottom sheet is showing
• Xcode
  • Slide out sidebar
  • Document tabs (just tabs?)
• SwiftUI
  • Lazy stacks and grids
  • Quick and easy app setup template