[ Background Conversations ]
[ Applause ]
Hello, everyone, and welcome to What's New in Swift Playgrounds.
My name is Connor.
I'm an engineer on the Swift Playgrounds Team.
And today, along with my colleagues Grace and Najla, I'll be sharing with you some of what's new in Swift Playgrounds since last year's conference.
Today's session will be broken up into three parts.
First, we'll take a quick look at the Playground book format to ensure that everyone is on the same page.
Then, we'll talk about many of the enhancements which have been made to support building better Playground books.
And finally, we'll introduce a brand-new API for interacting with and connecting to Bluetooth accessories in Playgrounds, allowing you to provide a consistent user experience.
So let's get started by talking about Playground books.
Swift Playgrounds supports two file formats, the classic Playground file format used by Xcode as well as the Playground book file format, which allows you to control the experience which your users see.
Playground books are split up into chapters, which are then further subdivided into pages.
Playground books may contain resources which are used either at runtime or in the prose which you show to your users.
All of this is done with a package-based file format.
If you're not familiar with what a package-based file format is, essentially instead of being a flat file, it's a folder which itself contains other files and folders which make up the document.
If we take a peek inside the Playground book, we can see inside there some PLIST files, some Swift files, and a bunch of directories which make up the structure.
Let's first take a look at the manifest files.
You can think of these as something that's very similar to an app's info.plist.
The manifest PLIST provides book-, chapter-, and page-level metadata, such as the name of the page or the icon which is used in the document browser.
Manifest files also specify the options for the book, chapter, or page, such as whether or not the live view is visible by default or if you want Playground logging to be turned on.
The other major component of a Playground book are Swift files, and there are three different kinds of Swift files inside of Playground books.
The first of these is the Contents.swift file.
This is the source file with which your users interact, and it's where you can store the prose which is shown to your user inside of special markup comments in the Swift file.
There's also the LiveView.swift file.
This allows you to provide an always on live view, which provides a rich and interactive experience for your users for the entire time they're on the page instead of just when they're running their code.
And finally, you also have the auxiliary source files.
These are stored in the book, chapter, and page and allow you to provide additional API through separate Swift modules which are automatically imported at each level.
For more information on the Playground book file format, I'd really recommend that you take a look at last year's session, Introducing Swift Playgrounds, where some of my colleagues go into this in a lot more depth.
There's also really great documentation available on developer.apple.com.
Let's now take a look at some of the new features in Swift Playgrounds since last year.
First up is support for copying code between pages.
This allows you to build a Playground book which continues a narrative from page to page while allowing users to evolve the code that they're writing.
So when I open up a page that uses this feature, as a user, I see a prompt to either bring over my code from the previous page or to start coding immediately.
If I then tap on the button to bring my code forward, then my implementation from the previous page is automatically copied for me and the source editor is shown, allowing me to begin coding.
The next new feature is support for speed control in Swift Playgrounds.
This allows you to control the speed of execution, and there's two forms for this.
First up is support for stepping through code as it executes.
So if you tap the speed control in the live view at the bottom left, you can select Step Through My Code, and then as the code executes in the live view, the line of code, which corresponds to the current action, is highlighted in the source editor.
So you can see, as Bite moves around the puzzle world, the line of code directing the action is highlighted.
Swift Playgrounds now also supports running faster than the default speed if your Playground book supports it.
So again, you can tap on the speed control in the live view and then select Run Faster or Run Fastest.
Learn to Code 1 and 2 take advantage of this feature to make Bite move more quickly throughout the puzzle world.
Swift Playgrounds will now show runtime errors which occur in your Playgrounds.
So in this case, I have created an array with five items, and then I try and access the item at index 5, which results in an index out of range error.
Swift Playgrounds is able to determine which line of code caused execution to crash and then highlights the line with the text that's provided.
Users are now able to add, delete, rename, reorder, and duplicate pages inside of Playground books, which they create inside of Swift Playgrounds, including all of the Apple-provided starting points.
Swift Playgrounds is now localized into a few more languages to increase its reach.
So Swift Playgrounds and all of the Apple-provided content is now available in simplified Chinese, Japanese, French, German, and Latin American Spanish.
And you as an author can localize into any of these languages or any of the others which iOS supports.
[ Applause ]
Coming in Swift Playgrounds 2 is support for the iOS 11 SDK, and this means that a handful of new frameworks are now available for use in Playgrounds in Swift Playgrounds 2.
This includes ARKit, CoreML, IOSurface, PDFKit, and Vision.
Additionally, Playgrounds may now access the camera if they're running on iOS 11.
You can use the AVFoundation APIs to get access to the camera.
It's important to note, though, that this won't work on earlier versions of iOS, so if your Playground depends on the camera, we recommend that you set its deployment target to iOS 11.
And now, let's hop into a demo to take a look at a couple of these features.
[ Applause ]
OK, so here I have Swift Playgrounds, and I'm going to go ahead and launch it.
And Najla, Grace, and I are each working on Playground books representing kind of our kitchen where we're going to use Swift code to make some things.
And I'm going to start out by making a cake.
So I'll go ahead and open up my Playground book.
And we're going to start from the very beginning by making our, making some butter on our own.
So we've got this makeButter function and we've got the cream that we need for the butter.
So I'll go in and just add some code to churn that cream, which will then produce the butter that we want.
I can then run my code, and then we'll see in the live view that, hey, we got the cream, we've churned it, and then we have butter.
So it's then, Swift Playgrounds is then telling us that we've successfully completed the task.
I'll go on to the next page, and we're going to use that butter to make some frosting.
And instead of having to take a author-provided version of butter, I'm going to be able to pull my butter function from the previous page.
So I'll tap on Bring Over My Code, and then I see the makeButter function that I implemented is copied over to this page.
Additionally, the authors provided a makeFrosting function, which I'll then fill out.
So we've got all the ingredients we need for the frosting: the butter, powdered sugar, vanilla, and milk.
So I'll go ahead and make this return frosting, which I can do by mixing together these ingredients.
Let's look at the powdered sugar, the butter, the vanilla, and the milk.
And because I want to see exactly what happens to make this frosting, I'm going to enable Step Through My Code.
We'll see that we start the makeFrosting function, then we start to make butter, and we see the live view update as we make the butter.
Look at the powdered sugar, the vanilla, and the milk.
Then, we mix it all together to get frosting.
And so there we've completed the task on this page that we want.
So I'll move forward.
And now, we're going to go on and start making the cake.
But if I look at this, there's a lot of ingredients here that it wants me to collect, and I think there's going to be a little bit more work that I need to make this cake, and I'm kind of running short on time.
So I'm going to pretend that I'm on a cooking show and move straight to the end.
So I'll tap on this Let's Eat Cake page.
And Swift Playgrounds is telling me that I should go back and finish making this cake, but because I can go to any page at all, I'm able to tap in this Start Cooking on This Page button, which will then use the default implementation of the cake.
So we'll see the authors provided a makeButter and a makeFrosting function.
Then, the author has all of the ingredients needed for the cake.
The ingredients are then mixed together into a batter, which is then baked in an oven, and then we let that hot cake cool before frosting it.
So I'm going to come in here at the bottom and just call a function to eat the cake.
Because I want to go as quickly as possible to get through this, I'm going to actually tap on Run Fastest, which will then go through each step very, very quickly.
We can see in just a matter of moments I have the cake that I was looking for.
So great. I've now showed you a handful of features that are new in Swift Playgrounds.
Let's now take a look at how you can adopt them in your Playground books.
[ Applause ]
The first feature I showed you was support for copying code between pages.
This allows you to craft a Playground book where the user is constantly refining their implementation of a particular function or of other code.
For a user, when I look at a page which is being used as the source of copyable code, I really don't actually see much difference.
I just see an editable area where I can insert some code.
But if we take a peek at the code underneath, there's a little bit of stuff that you as the author provide to let Swift Playgrounds know what should be copied.
That is these copy source tags, which allow you to tag a region of the page with an identifier, which then you can reference later.
On a page onto which code is being copied, as a user, when I first open it, instead of being presented with a source editor, I'm presented with the option to either copy my code from the previous page or use the default implementation.
If I haven't yet successfully completed that page, instead of being asked if I want to copy code, I'm asked if I want to go back to that page to finish it first.
But I'm still presented with the option to start working on this page immediately.
Once the user makes a selection to either copy code or use the default implementation, then the regular source editor's presented with a code they expect.
Let's take a look at how this happens in the source code itself.
And it's very similar to the other case.
Instead of providing copy source tags, though, you provide a copy destination tag, which tells Swift Playgrounds the page from which you want to copy as well as the identifier on that page for the range of code which should be copied because you're able to copy code from multiple sources onto a single page.
Then, you place this inside of the editable code region into which you want to place the copied code.
There's also a little bit of stuff that needs to be placed in the manifest file to support copying code between pages.
So there are a couple of keys, the ready to copy instructions and the not ready to copy instructions.
These refer to markup text, which is shown with Swift Playgrounds is either ready to copy because the user has successfully completed the previous page or when it's not ready to copy because the user hasn't yet finished the page.
And you're able to provide the text that makes sense for your playground book to tell the user what they should be doing here.
There are also a handful of optional keys the CopyCommandButtonTitle key, the NavigateCommandButtonTitle key, and the DefaultCommandButtonTitle.
These all refer to the titles of the buttons so that you can customize them to your Playground book.
It's worth noting, though, that if you don't provide any of these keys, Swift Playgrounds will use a default title instead.
It's not possible to hide any of these buttons in the UI.
The other feature, which I showed you, was support for controlling the speed of execution in Playgrounds.
Swift Playground now supports both stepping through code as well as running faster than the default.
The Step Through My Code mode as well as its sibling, Step Slowly, is enabled for all Playgrounds.
This is because users should always be able to enable this mode to see what's happening in their code.
Run Faster and Run Fastest, however, we can't enable those by default because not all Playground books can actually run faster.
Some operations, you just can't make it go faster.
So Playground pages in books may opt into run faster or in running fastest.
Let's take another look at how Step Through My Code works.
So when the user taps on the run, the speed control, rather, and selects Step Through My Code, then their, the code runs normally, but the line of code which is running is highlighted on the left.
Let's see how this works under the hood.
So if you have in your Playground book some straight-line code that's running synchronously like this where we create a string, iterate over each character of the string, and then print it out, there's actually nothing that you need to do.
Swift Playgrounds will automatically insert delays so that every visible line of code takes an appreciable amount of time so this code will highlight correctly.
There is one case which needs some special care, and that's if you as a Playground book author are providing asynchronous API to your users, which under the hood is actually implemented asynchronously.
So in this case, we have a moveForward function, which is going to just schedule some work on a background queue.
While this would be a good practice in an app, it's not so great for a Playground because when you when the user calls the moveForward function, it will only be highlighted for the amount of time it takes to schedule this background work, not for the amount of time it takes to actually move forward.
So instead, you need to make your functions which appear to be synchronous actually be synchronous, and you can do this with a little bit of code.
So first, at the top of your function, you can get the current run loop and then have a variable, which indicates whether or not the asynchronous operation has completed.
Then, at the end, you need to make sure that the function doesn't exit until the asynchronous operation has finished.
So you can do that by having a while loop which keeps the current run loop running until the didFinish flag is set to true.
In the callback, after your, whatever work you would be normally doing in the callback, you need to do a little bit extra.
First, you need to set the didFinish flag to true so that that while loop will exit.
You then need to run a lock on that run loop to tell it to stop so that the CFRunLoop run call will terminate.
And then, because of how the CF API works, you need to tell that run loop to wake up so that it will actually perform with the block that you scheduled.
The other half of speed control is support for running faster than the default speed.
Again, this is accessed through the speed control in the bottom left of the live view.
The user can tap on Run Fastest if it's supported, and then the Playground book does whatever it can to run faster or run fastest.
Since not all Playground pages can actually run faster, this requires an opt in from the author to enable these modes, and that's by setting the maximum supported execution speed to the maximum speed at which you can run.
If you leave this out, Swift Playgrounds will infer the default, the speed to the normal speed, which would mean that only the Run My Code Speed would be shown.
But you can also set it to faster or fastest depending on the fastest possible speed you support.
To adopt this feature, you just need to listen for a notification, which is posted when the user changes the execution speed.
That's this playgroundPageExecution ModeDidChange notification.
Instead of this callback, you can then ask the current Playground page for its execution mode and then update animation speeds or anything else for the new mode that the user has selected.
So with that, I'd like to bring my colleague, Grace, up on stage to talk about a handful of the other enhancements we've made to Playground books.
[ Applause ]
I'm so excited to talk to you about some of the enhancements that have been made to the Playground book format to better serve you all as authors and developers.
The first thing that I'd like to talk about is the introduction of the minimum Swift Playgrounds version key.
This is an optional string that will allow you to specify the minimum app version that can be used to open your documents.
Next, let's talk about the deployment target and the Swift version keys.
These keys have been present since the original release Playground book format, but earlier versions of the app had hard-coded iOS 10.0 and Swift 3.0 to these keys.
However, now your selections are honored.
Additionally, Swift version is now a required key for you to fill in.
This is all stored in the book level Manifest.plist.
And for Swift version, you should use the major and the minor version of Swift that you used to write your book.
Swift Playgrounds now allows you to specify subtitles for your document.
This is another optional string in the book level Manifest.plist, and if you don't provide it, Swift Playgrounds will just fill in the Swift version of your book.
So here in Grace's Kitchen, I've used Cooking with Playgrounds for my subtitle, and it shows below my document in the document picker.
Next, Swift Playgrounds has replaced the single Resources directory with two resources, two Resource directories, PublicResources and PrivateResources.
Any files that you want your users to be able to access while they're using your book, either in the file picker or the image picker, should go in the PublicResources directory.
And any files that you don't want your user to be able to access should go in the PrivateResource directory.
Those files could be localization files or hints files that you don't want your user to peek at while they're using your book.
Next, Swift Playgrounds now allows you to create specific runtime issues that will show up in line.
So to do this, you can call fatal error, and the string that's passed in will show up in line with other results while your user is using the book, if they ever hit it.
So next, let's talk about how you can support user-editing in your Playground books through the use of template pages.
A new feature in Swift Playgrounds allows your users to add, remove, rename, duplicate, and reorder pages within your Playgrounds books.
You can see this functionality already in our starting points templates.
But to show it off a little bit here, I'd like to hop into a demo.
[ Applause ]
So I'm going to go ahead and open up Grace's Kitchen, and this is a book that I created for my users to have a recipe book on their iPad with Swift code.
So in my kitchen, I have three recipes: butter, frosting, and cake.
And my mom would tell me that this is not the most healthy recipe book, so I want my users to be able to add some of their own.
So if we go into the Edit button, I can add a page through the + button in the top left.
And then, I'm going to add a recipe for pancakes.
Not the most healthy, but we're getting there.
So if I tap Done and then I navigate to my Pancakes page, we can see that I as the author have provided some prose, and then for sake of time, I've also written out our pancakes recipe in code.
And now, when I tap Run My Code, this Playground book will intelligently generate a recipe for pancakes.
And to show you how you can adopt this in your books, let's hop back to the slides.
[ Applause ]
The first thing that you'll need to do is specify a template page.
Template pages are supported in the last chapter of your book, and this key should go in the chapter's Manifest.plist.
And what I mean by template page is the page that's instantiated when your user adds a new page to your book.
So to specify this, you should use the TemplatePageFilename key.
This is a string, and the string should be the value of the file that should be instantiated.
So here I've used Template.playgroundpage.
Next, I'd like to talk about the difference between InitialUserPages and pages.
Both of these are keys that store an array of page filenames.
InitialUserPages are pages that the author has created that they want the user to be able to interact with in that way of duplicating, renaming, reordering, et cetera.
If you don't want your user to be able to interact with them in that way, then you should store them in the pages key instead.
So here's the file structure for my Playground book.
We can see that the Manifest.plist in is in the chapter level, and that should hold the InitialUserPages key and the TemplatePageFilename key.
And then, in my Pages directory, I have my Butter, Frosting, and Cake pages, and I also have my Template page, which is what should be instantiated when a user adds a page.
And next, I'd like to pass it off to Najla to talk about localization.
[ Applause ]
So as Connor mentioned earlier today, the Swift Playgrounds app, along with Apple-provided content, is now localized into six languages.
But if you wanted to localize your own Playground books, then you're not limited to these six languages.
Localizing a Playground book is a lot like localizing an app in that you have the same resource [inaudible] directories, and strings files.
So to localize your Playground book, you're going to need to set the development region key.
The development region key specifies what base language this book was written in, and it's required even if you haven't localized your book yet.
If you've, if you are familiar with localizing apps, the development region key is the Playground book equivalent of CFBundleDevelopmentRegion.
So just like apps, Swift Playgrounds supports localizing content with strings files, and there are four kinds of strings files that we want to mention today: ManifestPlist, Prose, EditableFields, and QuickHelp.
Now, earlier in this session, Grace talked about public versus private resource directories in your Playground books.
And since the strings files are used to communicate with the app itself, it's best that they live in the PrivateResources directory of your book.
So let's hop into some more detail about these strings files.
So Swift Playgrounds supports localizing content from ManifestPlists using a ManifestPlist.strings file.
And an example of some localizing ManifestPlist content in Learn to Code 1 is the table of contents that you can see with all of the exercises.
Let's take a closer look at the first exercise in Learn to Code 1, which is called Issuing Commands, and here it is in simplified Chinese.
So Playground book has a ManifestPlist at every level at the book level, chapter level, and page level.
Information about an exercise's title is pulled from the page level ManifestPlist, and here's the page level ManifestPlist for the Issuing Commands exercise.
You can see that there's a key called Name, and its value is the title.
The simplified Chinese title for Issuing Commands is pulled from the simplified Chinese ManifestPlist.strings file.
And here you can see that the name is defined as a simplified Chinese of Issuing Commands.
So Playground markup blocks are also supported.
You can also localize Playground markup blocks in Swift Playgrounds using a Prose.strings file at the page level.
And here's some prose from Issuing Commands that's been localized into German.
To do this, in the Contents.swift file, it specifies a block of localized prose using a localized tag, which takes a key.
This key is then defined in the German Prose.strings file as the German translation of our prose.
You can also localize editable fields in Swift Playgrounds by using an EditableFields.strings file.
An example of an editable field in Learn to Code 1 is that Tap to enter code string that you see in some exercises.
And here it is in French.
So in the Contents.swift file, it specifies an editable field with an editable code tag that takes the key that's the placeholder that we want to localize.
In our case, the placeholder is called Tap to enter code.
That placeholder is then defined in the EditableField.strings file for French as the French translation of Tap to enter code.
So in Swift Playgrounds 2.0, which you got a beta of on Monday, you can localize API documentation.
And here's an example of some API documentation from Learn to Code 1.
It's a move forward command that you can use to move Bite in its little world.
To localize your API documentation, you can use a QuickHelp.strings file.
In you AuxiliarySources file for your exercise, it specifies a block of localized documentation by using a localization key.
That key is then defined in the QuickHelp.strings file.
In our case, our documentation is in English, so this is the QuickHelp.strings file for English.
So along with using strings files to localize your Playground books, you can use a Hints.plist to localize default hints.
Here's an example of a hint from Issuing Commands that's been localized into Japanese.
So Issuing Commands only has one hint.
So in our Hints.plist for Japanese, we have one entry that represents our one hint, and its value is the Japanese translation of our hint.
So the localization support in Swift Playgrounds allows you to create really detailed and immersive Playground books for a larger audience, and we're super excited to see all of the Playground books that you localize.
If you want more information about how to localize your Playground books, we have a session later today on Localizing Content for Swift Playgrounds at 3:10.
So let's switch gears and talk about the PlaygroundBluetooth API, which is in Swift Playgrounds 1.5, which shipped on Monday.
So Swift Playgrounds provides full access to CoreBluetooth, which allows you to integrate accessories into your Playground books.
And if you've taken a look at some of the accessory Playground books available, you'll notice that they all have a really great and consistent Playground book experience.
And the Playground book API allows you to integrate that experience into your own Playground books.
So there are two main components of the PlaygroundBluetooth framework.
The first is the PlaygroundBluetooth Central Manager, which is responsible for all the logic to interact and manage accessories.
The second is the PlaygroundBluetooth Connection View, which allows you to customize a user interface that users use to interact with accessories.
They both have their own delegates, and the PlaygroundBluetooth Connection View has a PlaygroundBluetooth Connection View data source that provides specific information about an accessory.
So the PlaygroundBluetooth Central Manager provides an interface for connecting to and interacting with accessories.
It's really similar to CoreBluetooth's CBCentralManager, so if you've implemented that before in a Playground, then you could reuse code here.
The Central Manager can take an array of accessory UUIDs to search for, or you can specify to search for all accessories in the vicinity.
The PlaygroundBluetoothCentral ManagerDelegate has methods for interacting with accessories, such as connecting to and disconnecting from accessories.
So the PlaygroundBluetooth ConnectionView provides an interface for displaying the connection status of accessories and allows users to discover, connect to, and disconnect from accessories.
Here's an example of a Connection View that I've customized because my Playground book searches for a Bluetooth printer.
The PlaygroundBluetooth ConnectionViewDelegate has methods for customizing the UI and handling user interactions.
For example, you can use the titleFor delegate method to customize the Connection button.
In my case, I've customized it to say Select Printer.
Lastly, the PlaygroundBluetooth ConnectionViewDataSource is a protocol that's adopted by the Connection View that provides specific information about an accessory.
In my case, the data source provides information about my printer, its title, which is Najla's Printer, and that cute printer icon that's to its left.
You can provide this information using its one method.
So let's hop into a quick demo of the PlaygroundBluetooth framework in action.
[ Applause ]
So earlier today you saw Grace create a Playground page for making pancakes, and I love pancakes a lot, but I cannot cook.
So what I would really like to do is I would like this Playground book, in addition to generating the recipe, to be able to connect to a Bluetooth printer so that I can print it out and then give it to someone when I want them to make pancakes for me.
So let's go into my Playground book.
And what I've done is I've taken Grace's Pancakes page and I've integrated this cute, little Bluetooth printer.
So when I tap on Connect Printer, it's going to search for my printer.
And in addition to being able to generate this recipe, when I select Najla's Printer, it's going to print out the recipe.
So keep an eye on the printer and cross your fingers.
Here we go.
[ Applause ]
So, [laughs] so now, I have the recipe for pancakes and I can give it to Connor after this session.
[ Laughter ]
[ Applause ]
So we talked about a lot today.
You got an overview of all of the format changes that have happened in the past year.
You learned how to integrate copy code forward into your Playground books so that you can create a really nice narrative, how to create interesting user editable books so that users can then modify your template pages, how to localize your Playground books, and finally, how to integrate accessories into your Playground books.
For more information about this session, please visit developer.apple.com.
There are also a few related sessions that you can visit or watch online.
Thank you for watching our session, and we hope that you enjoy the rest of the conference.
[ Applause ]