At the Melbourne Xamarin Meetup November 2019 Meetup, I gave a second run of my  "(Some of) What's new in iOS13" talk, which (appropriately) covers new features and frameworks in the latest version of iOS. Since the talk included a number of new demos, this one ended up with the title "(More of) What's new in iOS13". You can see more about the original talk in my earlier post, which covered Dark Mode, PencilKit, ARKit and CoreML. In addition to those, the 'More of' edition included new segments on Multi-Window apps, Sign-in with Apple, and CoreNFC.

This meetup itself was streamed on Twitch, so you can also watch the full thing back at your leisure (~1h 15m):

Slides are available at the end of the post, and a little detail on each of the new areas from this talk is below.

Multi Window

WWDC Reference: Introducing Multiple Windows on iPad

On iPad, iOS13 (strictly, 'iPadOS') adds the ability for individual apps to work with more than one window.

There are various ways that a new window can be created - from the dock, from a shortcut item, via a drag and drop operation, or programmatically.

The positioning of an app's visible windows are fixed to a few variations (split pane or floating - same as with multi-app multitasking). However, the total number of windows an app can have (that is, including backgrounded windows) is effectively unlimited.

To model multiple window architectures, iOS13 introduces a few new supporting classes; importantly the UI(Window)Scene and UISceneDelegate classes - one of each will be instantiated for every new window created by the application. The UISceneDelegate, among other things, handles the 'UI lifecycle' of the window, so if you opt in to supporting multiple windows, iOS will stop calling the UIApplicationDelegate UI lifecycle methods and instead call them on the SceneDelegate(s) of the windows involved in the changes. Whilst multiple windows can offer a lot of power and flexibility, it does come at the cost of additional complexity. For comparison, I diagrammed an indicative object instance graph in single window and multi window scenarios.

Although it's true that the second example contains three windows (so we should expect it to be more complicated), everything on the left half of the diagram is required even when a single window is used. Supporting multiple windows also comes with other considerations such as:

• Accounting for iPhones of all versions, and iPads running iOS12 and lower (no multi-window support)
• Removing any baked in assumptions about the existence of just one window
• Seperating process-level concerns and initialisation from interface level initialisation
• Cross-platform experience

Given the above, I'd personally be looking at multi-window only if I had a really strong case for it in a mobile/tablet app. On the other hand, for an iPad-focussed app - given Marzipan - it might make sense to start adopting this now.

Sign In With Apple

WWDC Reference: Introducing Sign In with Apple

Sign In With Apple (illegally abbreviated to SIWA here and in the slides) is a new OIDC compliant (with some 'peculiarities') auth mechanism that ships with iOS13. It provides a streamlined auth experience for both users and developers, by leveraging features circumstances guaranteed by the use of a signed-in Apple device.

From the user's perspective, SIWA offers a familiar, convenient and privacy-friendly signup/auth flow. No passwords are involved, and the user can choose to share or hide personal details such as their name and email address, without compromising the functionality of the application.

When the user selects the 'Hide my email address' feature, Apple provides the developer with a random-looking email address, and relays any emails sent to that address to the user's actual address. The user can disable this relay from Settings at any time.

From the developer's perspective, SIWA also offers some benefits. Apple provides buttons and sign-in UI for the process that can be invoked with a small amount of code. SIWA also provides a stable user identifier across devices and a reliable assessment of whether it thinks the user is real (as opposed to being a bot).

According to its developer policy, Apple will require apps that rely solely on social login to include SIWA as a sign up/auth option. I read somewhere that it will be enforced for existing apps from March 2020 but don't quote me on that.

CoreNFC

WWDC Reference: CoreNFC Enhancements

CoreNFC allows developers to add Near-Field Communication (NFC) capabilities to their apps when running on devices with the appropriate hardware (all iPhones since the iPhone 7, but not iPads). First introduced in iOS11, CoreNFC has traditionally offered a relatively restricted set of features to developers (when compared to that of Android), essentially limiting interactions to NDEF tag reading. With iOS13, CoreNFC supports new features that significantly increase the applications of NFC on iOS devices.

NDEF tag writing:
It's now possible to write NDEF messages to tags using the WriteNdef method on INFCNdefTag. CoreNFC provides convenience methods for constructing string and URI-based NDEF payloads via the NFCNdefPayload.CreateWellKnownTypePayload overloads. The addition of NDEF writing helps bring iOS NFC capabilities closer to parity with that of Android.

Native tag protocol implementations:
In iOS13, CoreNFC also allows developers to interact with several kinds of NFC tags via their native protocols. This includes ISO7816, ISO15693, FeliCa, and MIFARE tags. With the appropriate entitlement, and use of the new NFCTagReaderSession and NFCTagReaderSessionDelegate classes, you can now detect these tags and send commands to them using dedicated interfaces:

For demonstration purposes only and not because I am a nerd, I was most interested in trying out the MIFARE tag support, knowing that tags in Nintendo Amiibo use that technology. After consulting the MIFARE datasheet and reverse-engineered Amiibo data structure, I was able to successfully detect and read game/character identifiers from an amiibo using MIFARE commands, which could then be send to Amiibo API to perform an Amiibo lookup. Cool!

(In practice, I found the scanning to be a little bit unreliable, but I could have been holding it wrong)

Not satisfied with just identifying an amiibo, I also investigated the legally, morally, and ethically murky world of Amiibo cloning. In the image of the MIFARE datasheet above, the FAST_READ command is shown, but there is also a WRITE command that allows data to be written to a specified page. With the right kind of blank tag (NTAG215), and a mechanism for decrypting and reencrypting an Amiibo dump, it's possible to use the WRITE command to clone an Amiibo in a manner that a Nintendo Switch considers valid.

Cloning Amiibo raises so many ethical and moral questions, but more importantly, it relies on secret Nintendo key material that shouldn't be checked into the repo. Given that, I removed the cloning implementation from the demo app before checking it in, but left the high level flow in the comments for the inspired reader. It isn't too difficult (standing on the shoulders of giants), but it is a little involved.

Demo App

The "Hello iOS13" demo app has been updated to include the new demos on Github: rdavisau/hello-ios13.

Slides

Links for the slides are below.

Slides (56): PDF