How to use iOS 11 Beta installed device with Xcode 8

By Manish Chauhan

Read

0 Comments

Read More Add comment

iOS 11: Machine Learning for everyone

By Manish Chauhan

Read

0 Comments

WWDC 2017 has made one thing very clear: Apple is going all in on machine learning on the device.

And they want to make it as easy as possible for app developers to join them.

Last year Apple announced the Metal CNN and BNNS frameworks for creating basic convolutional networks. This year we get lots of additions to Metal, a new computer vision framework, and Core ML: a toolkit that makes it really easy to put ML models into your app.

In this blog post I’ll share my thoughts on — and experiences with — the new machine learning stuff in iOS 11 and macOS 10.13.

Core ML

Core ML got most of the attention at WWDC and it’s easy to see why: this is the framework that most developers will want to use in their apps.

The API is pretty simple. The only things you can do are:

loading a trained model
making predictions
profit!!!

This may sound limited but in practice loading a model and making predictions is usually all you’d want to do in your app anyway.

Previously, loading a trained model was much harder — in fact, I wrote a library to take away some of the pain. So I’m happy that it’s a simple two-step process now.

The model is contained in a .mlmodel file. This is a new open file format that describes the layers in your model, the input and outputs, the class labels, and any preprocessing that needs to happen on the data. It also contains all the learned parameters (the weights and biases).

Everything you need to use the model is inside this one file.

You simply drop the mlmodel file into your project and Xcode will automatically generate a Swift or Objective-C wrapper class that makes it really easy to use the model.

For example, if you add the file ResNet50.mlmodel to your Xcode project, you can then write,

let model = ResNet50()

to instantiate the model. And the following to make a prediction:

let pixelBuffer: CVPixelBuffer = /* your image */

if let prediction = try? model.prediction(image: pixelBuffer) {
  print(prediction.classLabel)
}

And that’s pretty much all there is to it. You don’t need to write any code to load the model or to convert its output into something you can use from Swift — that’s all taken care of by Core ML and Xcode. Sweet!

Note: To learn what happens behind the scenes, you can select the mlmodel file in the Project Navigator and then click on the button that says (Swift generated source) to see the file with the generated helper code.

Core ML will decide for itself whether to run the model on the CPU or the GPU. This allows it to make optimal use of the available resources. Core ML can even split up the model to only perform certain parts on the GPU (tasks that need to do a lot of computations) and the other parts on the CPU (tasks that need a lot of memory).

Core ML’s ability to use the CPU has another big benefit to us developers: you can run it from the iOS simulator (something that’s not possible with Metal, which also does not play well with unit tests).

What models does Core ML support?

The ResNet50 example above is of an image classifier but Core ML can handle several different types of models, such as:

support vector machines (SVM)
tree ensembles such as random forests and boosted trees
linear regression and logistic regression
neural networks: feed-forward, convolutional, recurrent

All of these can be used for regression as well as classification. In addition your model can contain typical ML preprocessing steps like one-hot encoding, feature scaling, imputation of missing values, and so on.

Apple makes a number of trained models available for download, such as Inception v3, ResNet50, and VGG16, but you can also convert your own models with the Core ML Tools Python library.

Currently you can convert models that are trained with Keras, Caffe, scikit-learn, XGBoost, and libSVM. The conversion tool is a little particular about which versions it supports — for example Keras 1.2.2 works but 2.0 doesn’t. Fortunately, the tool is open source so no doubt it will support more training toolkits in the future.

And if all else fails, you can always write your own converter. The mlmodel file format is open and fairly straightforward to use (it’s in protobuf format and the specs are published by Apple).

Limitations

Core ML is great for quickly getting a model up and running in your apps. However, with such a simple API there are bound to be some limitations.

The supported model types are for supervised machine learning only. No unsupervised learning algorithms or reinforcement learning. (Although there is support for a “generic” neural network type, so you might be able to use that.)
There is no training on the device. You need to train your models using an offline toolkit and then convert the model to Core ML format.
If Core ML does not support a certain layer type, you can’t use it. At this point it’s impossible to extend Core ML with your own compute kernels. Where tools like TensorFlow are used to build general-purpose computational graphs, the mlmodel file format is nowhere near that flexible.
The Core ML conversion tools only support specific versions of a limited number of training tools. If you trained a model in TensorFlow, for example, you can’t use this tool and you’ll have to write your own conversion script. And as I just mentioned: if your TensorFlow model is doing something that mlmodel does not support, you can’t use your model with Core ML.
You cannot look at the output produced by intermediate layers; you only get the prediction that comes out the last layer of the network.
I’m not 100% sure but it seems that downloading a model update could be problematic. If you need to re-train often and you don’t want to push out a new version of your app every time you update the model, then maybe Core ML is not for you.
Core ML hides whether it runs on the CPU or the GPU — which is convenient — but you have to trust that it does the right thing for your app. You can’t force Core ML to run on the GPU, even if you really really want it to.

If you can live with these limitations, then Core ML is the right framework for you.

If not, or if you want full control, you’re going to have to roll your own with Metal Performance Shaders or the Accelerate framework — or both!

Of course, the real magic sauce is not in Core ML but in your model. Core ML is of no use if you don’t have a suitable model to begin with. And designing and training models is the hard part of doing machine learning…

A quick demo app

I put together a simple demo project to play with Core ML. As always, you can find the source code on GitHub.

This demo app uses the MobileNet architecture to classify a picture of a cat.

Originally this model was trained in Caffe. It took me a little effort to figure out how to convert this to an mlmodel file, but once I had my converted model it was really easy to build into the app. (The conversion script is included in the GitHub repo.)

The app isn’t very exciting just yet — it just outputs a top-5 prediction for a static image — but it does show how easy it is to use Core ML. Just a few lines of code is all you need.

Note: The demo app works OK on the simulator but crashes on device. Keep reading to find out why this happens. ;–)

Of course, I wanted to know what goes on under the hood. It turns out that the mlmodel file is actually compiled into an mlmodelc folder that goes into your application bundle. This folder contains a bunch of different files, some binary, some JSON. So with a bit of spelunking you can see how Core ML transforms the mlmodel before it actually gets deployed in your app.

For example, the MobileNet Caffe model uses so-called Batch Normalization layers and I verified that these are also present in the converted mlmodel file. However, in the compiled mlmodelc the Batch Normalization layers appear to have been removed. That’s good news: Core ML optimizes the model.

Still, it looks like it could optimize the structure of the model even more, since the mlmodelc still appears to include scaling layers that aren’t strictly necessary.

Of course, we’re only at beta 1 of iOS 11 and Core ML may still improve. That said, it might be worth optimizing your model before you give it to Core ML — for example, by “folding” the Batch Normalization layers — but this is something you’ll have to measure and compare for your particular model.

Something else you’ll have to check: whether your model runs the same on CPU and GPU. I mentioned that Core ML will choose whether to run your model on the CPU (using Accelerate framework) or the GPU (using Metal). It turns out that these two implementations may work differently — so you need to test both!

For example, MobileNet uses a so-called “depthwise” convolution layer. The original model was trained in Caffe, which supports depthwise convolution by making the groups property of a regular convolution equal to the number of output channels. The resulting MobileNet.mlmodel file does the same. This works fine in the iOS simulator but it crashes on an actual device!

What happens is that the simulator uses the Accelerate framework but the device uses Metal Performance Shaders. And due to the way Metal encodes the data, the MPSCNNConvolution kernel has the restriction that you can’t make the number of groups equal to the number of output channels. Whoops!

I’ve submitted a bug report to Apple, but my point is: just because the model runs OK on the simulator doesn’t mean it runs OK on the device as well. Be sure to test!

How fast is it?

I haven’t been able to test the speed of Core ML, since my new 10.5” iPad Pro is not arriving until next week (he he).

I’m particularly interested in seeing what the speed difference is between running MobileNets using my Forge library and using Core ML (taking into consideration we’re still on a very early beta).

Stay tuned! I’ll update this section when I have data to share.

Vision

Next up on the list of things to discuss is the new Vision framework.

As you probably guessed from its name, Vision lets you perform computer vision tasks. In the past you would probably have used OpenCV for this but now iOS has its own API.

The kinds of jobs Vision can perform are:

Finding faces within an image. This gives you a rectangle for each face.
Finding detailed facial features, such as the location of the eyes and the mouth, the shape of the head, and so on.
Finding things in images that are rectangular in shape, like street signs.
Tracking the movement of objects in a video.
Determining the angle of the horizon.
Transforming two images so that their content is aligned. This is useful for stitching together photos.
Detecting the regions in the image that contain text.
Detecting and recognizing bar codes.

Some of these tasks were already possible with Core Image and AVFoundation but now they’re all gathered inside one framework with a consistent API.

If your app needs to do one of these computer vision tasks, you no longer have to roll your own implementation or use someone else’s library — just use the Vision framework. You can also combine it with the Core Image framework for even more image processing power.

Even better: you can use Vision to drive Core ML, which allows you to use these computer vision techniques as preprocessing steps for your neural network. For example, you can use Vision to detect the position and size of a person’s face, crop the video frame to that region, and run your neural network on just the part of the image where the face is.

In fact, any time you’re using Core ML with images or video it makes sense to go through Vision. With “raw” Core ML you need to make sure your input image is in the format the model expects, but with Vision the framework takes care of resizing the image, etc. It saves a bit of extra effort on your part.

In code using Vision to drive Core ML looks like this:

// the Core ML machine learning model
let modelCoreML = ResNet50()

// link the Core ML model to Vision
let visionModel = try? VNCoreMLModel(for: modelCoreML.model)

let classificationRequest = VNCoreMLRequest(model: visionModel) { 
  request, error in
  if let observations = request.results as? [VNClassificationObservation] {
    /* do something with the prediction */
  }
}

let handler = VNImageRequestHandler(cgImage: yourImage)
try? handler.perform([classificationRequest])

Note that VNImageRequestHandler takes an array of request objects, allowing you to chain several computer vision jobs together, like so:

try? handler.perform([faceDetectionRequest, classificationRequest])

Vision makes computer vision really easy to use. But the cool thing for us machine learning folks is that you can take the output of those computer vision tasks and feed it into your Core ML model. Combined with the power of Core Image that makes for one hell of an image processing pipeline!

Metal Performance Shaders

The last major topic I want to talk about is Metal, Apple’s GPU programming API.

A lot of my work for clients this year has involved building neural networks with Metal Performance Shaders (MPS) and tuning them for optimal performance. But iOS 10 only provided a few basic kernels for creating convolutional networks. Often it was necessary to write custom kernels to fill in the gaps.

So I’m happy that with iOS 11 the number of available kernels has grown a lot, but even better: we now have an API for building graphs!

Note: Why would you use MPS instead of Core ML? Good question! The biggest reason is when Core ML doesn’t support what you want to do, or when you want full control over the process and squeeze out the maximum possible speed.

The big changes in MPS for machine learning are:

Recurrent neural networks. You can now create RNN, LSTM, GRU, and MGU layers. These work on sequences of MPSImage objects but also on sequences of MPSMatrix objects. That’s interesting because all the other MPS layers deal with images only — but obviously that’s not very convenient for when you’re working with text or other non-image data.

More datatypes. Previously weights were supposed to be 32-bit floats but now can be 16-bit floats (half precision), 8-bit integers, or even binary. Convolution and fully-connected layers can be done with binary weights and binarized inputs.

More layers. Up until now we had to make do with plain-old regular convolution and max/average pooling, but as of iOS 11 MPS lets you do dilated convolution, subpixel convolution, transposed convolution, upsampling and resampling, L2-norm pooling, dilated max pooling, as well as a few new activation functions. MPS doesn’t have all the Keras or Caffe layer types yet, but the gap is closing…

More convenient. Working with MPSImages is always a bit weird because Metal organizes data in slices of 4 channels at a time (due to images being backed by MTLTexture objects). But now MPSImage has methods for reading and writing data that don’t break your brain as much.

Also convenient is that MPSCNNConvolutionDescriptor has a new method that lets you set the batch normalization parameters on the layer. This means you no longer have to fold the batch normalization into the convolution layer weights yourself but MPS will do this for you. Very handy!

Performance improvements. The existing kernels have become faster. That’s always good news. 🏎

Graph API. This is the big news as far as I’m concerned. Creating all the layers and (temporary) images by hand was always a nuisance. Now you can describe a graph, just like you would in Keras. MPS will automatically figure out how large the images need to be, how to deal with padding, how to set the offset of your MPS kernels, and so on. It can even optimize the graph behind the scenes by fusing layers.

It looks like all MPS kernels are now serializable with NSSecureCoding, which means you can save a graph to a file and later restore it. And doing inference with this graph is now just a single method call. It’s not as easy as Core ML just yet, but using MPS is definitely a lot less work than before.

One thing that is not clear to me yet is whether you can write your own compute kernels and stick them into this graph. In my client work I’ve found that often there’s a need for a preprocessing step, which requires a custom shader written in the Metal Shading Language. As far as I can tell, there does not seem to be an “MPSNNCustomKernelNode” class. This needs more investigating!

Conclusion: the Metal Performance Shaders for machine learning have become a lot more powerful with iOS 11, but most developers should probably stick with Core ML (which uses MPS under the hood).

Note: The new graph API makes my Forge library pretty much obsolete, unless you want to keep supporting iOS 10 in your apps. I will be porting the example apps to the new graph API soon and I’ll write a more detailed blog post about it then.

Odds and ends

Some other new stuff that was announced:

Accelerate: It seems that BNNS in the Accelerate framework didn’t get much of a functionality update. It finally has a Softmax layer but none of the new layer types that MPS got. Maybe that’s all right: using the CPU for deep neural networks isn’t probably a good idea anyway. That said, I love Accelerate and it’s got loads of goodies. And this year it did get more support for sparse matrices, so that’s cool.

Natural Language Processing: Core ML is not just for images, it can handle lots of different kinds of data including text. The API to use is the NSLinguisticTagger class that has been around for a while but has become much more efficacious with iOS 11. NSLinguisticTagger now does language identification, tokenizing, part-of-speech tagging, lemmatization, and Named Entity Recognition.

I don’t have a lot of experience with NLP, so I can’t really say how it stacks up against other NLP frameworks but NSLinguisticTagger looks quite powerful. This API seems like a good place to get started if you want to add NLP to your apps.

Read More Add comment

How we cut our iOS app’s launch time in half (with this one cool trick)

By Manish Chauhan

Read

0 Comments

Building with frameworks at Automatic has sped up our development workflow and improved our code quality by enforcing strong boundaries between our components. In total, our iOS app contains over 40 first and third-party frameworks: one for consuming our HTTP APIs, another for interacting with our hardware devices via CoreBluetooth, and so on. Although this pattern has made development easier, it came with a cost: slow app launch times.

This slowdown happens because every dynamic framework adds overhead for dyld to do before an app’s main() function is called (known as “loading, rebasing, and binding”). In this WWDC 2016 talk, Apple suggests replacing dynamic frameworks with static archives to mitigate this. To take this approach, we rebuilt as many of our dynamic frameworks as possible statically and then merged them into a single monolithic dynamic framework named AutomaticCore.

We used DYLD_PRINT_STATISTICS to measure our app’s pre-main() launch times with a cold dyld cache (after a reboot of iOS) before and after we merged our frameworks. The difference was dramatic: our app’s launch time was cut in half:

Apple wasn’t exaggerating when they said too many dynamic frameworks could slow down your app’s launch time. However, merging our dynamic frameworks wasn’t trivial: we had to rework our development workflow to build our app this way from now on.

Here’s how

We use Carthage for dependency management at Automatic. However, when we dug into what it would take to rebuild our frameworks statically, we found that it was not possible with the way that Carthage worked at the time. Thankfully, Carthage is written in Swift, so it was easy to dive in and make the necessary changes to support this.

It was not trivial to add support to Carthage for building static archives (.a files). However, with some minimal changes, we were able to update Carthage to support building static frameworks (.framework files). Static frameworks are just like static archives, but packaged differently. They have a similar structure to dynamic frameworks, but with a static Mach-O file in place of a dynamic one.

Once a new version of Carthage was released with our changes integrated, building static frameworks was as simple as overriding some build settings when building our dependencies (see below). This was great news because we didn’t need to make changes to any of the third-party Carthage-compatible projects we depend on to build them statically.

Let’s quickly discuss what it takes for Xcode to produce a static framework from a target that normally builds a dynamic framework. To build an Objective-C dynamic framework target statically, you only need to override one build setting: MACH_O_TYPE = staticlib. However, if you’re attempting to build a Swift dynamic framework target statically, things get a bit more complicated (Keith Smiley of Lyft deserves kudos for this workaround). Since this Swift solution works for both cases (Objective-C and Swift frameworks), it’s the path we took. To briefly summarize the approach, we create a temporary xcconfig file with the necessary build setting overrides, and then set that file as the XCODE_XCCONFIG_FILE environment variable during our invocation of carthage build. This environment variable causes the build settings in this temporary file to override the build settings defined by any project built with xcodebuild (which Carthage uses under the hood). With this change, Carthage now produces static frameworks in Carthage/Build directory instead of dynamic ones.

Next, we needed to merge these static frameworks together into a single monolithic dynamic framework. To do so, we first created a new dynamic framework target in our application’s Xcode project. We named this target AutomaticCore.framework, since it would contain all of the “core” dependencies of our app and its app extensions. We then linked each of our shared static frameworks built by Carthage into this target. Linking a static framework into a target is very similar to linking a dynamic one—just drag and drop the .framework file into the “Link with Libraries” build phase. Next, we dynamically linked the “AutomaticCore” framework into our application and its app extensions, and finally embedded it into the Automatic.app package using a “Copy Files” build phase with a “Frameworks” destination. To ensure that all of the symbols from our static libraries were included in AutomaticCore, we passed the -all_load flag to the linker by adding it to the OTHER_LDFLAGS build setting.

How we merge many static frameworks into a single monolithic dynamic framework

Since we have app extensions that share many of the dependencies of our app (e.g. a Today Widget), we needed to use a merged framework to prevent duplication. If we were to statically link each of the shared frameworks into both our app and our app extension separately, we would have duplication between their executables, inflating our app bundle size. However, for frameworks that our app depends on exclusively (e.g. our framework for showing a support ticket composer interface), we found that it was acceptable to statically link them directly into our primary app, rather than AutomaticCore.framework.

We needed to make some additional changes to get our frameworks containing bundled resources working after we built them statically. When a dynamic framework is linked and embedded within an application, its resources are automatically made accessible to consumers. However, unlike dynamic frameworks, static frameworks are not embedded—meaning we needed to do some extra legwork to make their resources available. To do so, we explicitly added any required resources from the root of the static framework package to the target that it was linked into. This change allowed our resources to be loaded successfully again. Depending on the way that your frameworks reference resources, some code or bundle changes may be required to get your resources loading successfully again at runtime. For us, no additional changes were required.

Finally, we found that we needed to add some additional linker flags to our targets that link with static frameworks. Since some of our frameworks use Objective-C extensions, we needed to pass the -ObjC flag via the OTHER_LDFLAGS build setting to allow for Objective-C extensions in static frameworks to be called without causing a runtime crash. Additionally, for frameworks that depend on system libraries like libz, we had to link with them explicitly to fix missing symbols errors—whereas previously this linkage was inferred. To do so, we included flags like -lz in the OTHER_LDFLAGS as well.

Conclusions

We were delighted with the performance improvements we experienced after merging our dynamic frameworks together. While we feared adopting this pattern would force us to rearchitect our app or fork many third-party dependencies, it surprisingly turned out to require only a small number of changes. If you’re encountering similar pains with your app’s launch times, we hope that our experiences will be helpful in guiding you to a solution.

Read More Add comment

11 Considerations to Update Your App for iOS 11

By Manish Chauhan

Read

0 Comments

Another WWDC keynote has come and gone. 2017 saw Apple focus on six particular areas, including announcements for the Apple TV, Apple Watch, Mac, iPad, the new HomePod, and of course, iOS 11. All of these impact the work we do at Savvy Apps, but the most significant of all is iOS 11.

As we've covered in the past, Apple gives special attention to apps that will be ready for iOS 11 by launch day. When you update your app to the latest SDK or add features from the newest version of their operating systems, you'll have a better chance of being featured in the App Store. Whether you're building a new app that can more immediately take advantage of what was announced at WWDC, you see a new feature that can help your existing app, or you simply want to do a compatibility update, here are 11 considerations for updating your app for iOS 11.

Core ML in iOS 11 Provides Machine Learning Models

Apple introduced machine learning in iOS 10 and has extended that functionality with Core ML in iOS 11. The power of Apple's approach with Core ML is that you really get to take advantage of the device's CPU and GPU. Comparatively, Google's TensorFlow was designed to run in the cloud. TensorFlow Lite, announced at Google I/O recently, runs on devices as an alternative solution. Since Apple from the start has focused on having CoreML run specifically on their devices with products like Siri, Camera, and QuickType, there may be a near-term advantage. It's all still early in the machine learning age, especially when it comes to apps.

Apple points to two main uses initially: computer vision machine learning and natural language for text analysis. The iOS 11 Vision framework uses can range from text, barcode, face, and landmark detection to object tracking and image registration. Check out additional details on integrating a Core ML model into your iOS 11 app and the NSLinguisticTagger.

ARKit in iOS 11 Offers Native Augmented Reality

The second of the two largest, new frameworks announced in iOS 11 is ARKit. ARKit will transform apps like Pokémon Go, the rage of 2016, by giving them a native augmented reality (AR) framework. Don't tune out though if you're not building an augmented reality-driven app.

AR has been found in apps long before it was more widely popularized for entertainment purposes in recent years. Yelp popularized AR with its Monocle feature way back in 2009. Monocle, which has since been refined, allows users to see restaurant review ratings overlaid directly on what is seen through a camera view. Similarly, real estate, sightseeing, or any apps that have a "real world" component can benefit from AR.

That doesn't mean that some of the more exciting uses for ARKit won't focus on games, fun, or amusement. Apple will likely discuss uses in their ARKit introductory session.

iOS 11 Further Refines iOS Visual Design Language

The least explicit of all updates at WWDC 2017 relates to the iOS visual design language. It may be one of the more important ones though and hints at what will come in future versions of iOS.

Going back to 2013, iOS 7 completely changed the interface of iOS. Generally described as being "flatter," iOS 7 focused on removing skeuomorphic attributes while adding rounded corners, a grid system, and thinner typefaces. A complaint of iOS 7 though was that it was not as accessible overall, especially for those with visual impairments or aging eyes.

With the redesign of Apple Music in iOS 10, Apple introduced a number of changes. They included larger font sizes, thicker typefaces, and more contrast. One of the largest additions for iOS 11, the all new App Store, appears to very closely follow Apple Music's styles. Apple will also release a redesigned podcast app in iOS 11 that seems to follow the same styles. Third-party apps should take note of these new design cues and ensure they understand what great app design looks like.

New iOS 11 Product Page in App Store

Apple has a useful rundown of the all-new iOS 11 App Store and completely redesigned app product page.

The product page is getting new attributes such as a subtitle that Apple says can be tested. It's not clear at this point if that testing could be done with a tool Apple would offer or just a suggestion. It's also not clear how a subtitle may or may not impact App Store Optimization, and that likely won't be known for some time.

Previously, Apple offered a single app preview, which is a clip users can watch before downloading your app. That will now increase to up to three previews. Apple must have some data that shows that app previews drive downloads. So if you haven't done app previews in the past, definitely consider adding them and check out Apple's app preview tips. On a quick related note, screenshot images remain unchanged. Remember though that the first two screenshots show in search results.

Start In-App Purchases From the App Store

Although it's related to the product page, it's worth breaking out the following change: users can now start in-app purchases from the App Store in iOS 11. In-app purchases will get their own promotional image and description. They also can be returned specifically in search results or in the new "Today," "Games," and "Apps" tabs.

Apple notes that the SKPaymentTransactionObserver method must be used for enabling in-app purchases from the App Store itself. Should a user not have your app yet, they will be prompted to download or purchase it. Don't forget about using auto-renewable subscriptions as they can better help sustain your app over time.

Use iOS 11 Business Chat to Better Engage Users

There are a number of great solutions to ensure users can immediately get answers from you. That includes knowledge bases like HelpScout or messaging platforms from Drift and Intercom. Apple is getting into this space with its "Business Chat" tool, which wasn't covered specifically during the keynote itself.

We've actually tried this feature from within Apple's own apps. This approach makes a ton of sense for Apple and follows their move to allow developers to respond to reviews earlier in 2017. What will be interesting is if Business Chat can really compete with others in the space, especially since they integrate across platforms, or if it's a more lightweight solution. At first glance it appears to support apps and the web.

One of the largest complaints with Apple's ecosystem, even today, is that businesses and developers get very little customer access. Business Chat might start to change that, but the question will be by how much. Check out Apple's WWDC session on Business Chat to learn more.

Take Another Look at iMessage Apps in iOS 11

We were excited for the new Messages framework launched in iOS 10. It had two major problems though: discoverability and usability. Apple is attempting to address both with some user experience changes in iOS 11.

The revamped "App Drawer" in the Messages app will now allow iMessage apps to be quickly accessed. With the more prominent position, it should also be easier to discover and install new iMessage apps themselves.

We're not sure if this particular change could allow sustainable standalone iMessage apps. Both iMessage apps and stickers though could definitely help with increasing user engagement for your app, so they might warrant another look. Apple has a session on what's new in iMessage apps for iOS 11 that could be worth reviewing.

iOS 11 Phased Releases for App Store Updates

A nice addition for App Store updates will be what Apple calls "phased releases." While available on other platforms, Apple has required an app update to hit all users at the same time up until now.

This change can be useful in a few ways. First, if your app has a backend, it will help ensure your server infrastructure is not impacted all at once. Second, it may help from a testing standpoint if you want to see how a feature takes with a wider audience before it is available to all users. And finally, it may be able to help from a marketing standpoint. For example, you may want to release an update to specific regions or avoid certain times. Of course that all depends on how Apple implements the feature.

Drag and Drop, Browse Files, and App Password Autofill

We previously outlined how important Size Classes are, especially for Slide Over and Split View. iOS 11 furthers this importance with support for drag and drop within UIKit, including across apps on the iPad.

iOS 11 also adds view controllers for browsing documents locally and remotely. Although there's an emphasis on iCloud documents, this appears to be able to extend support to third-party services such as Dropbox and Google Drive. See more information on adding document browsing to your iOS 11 app from Apple.

A final, nice addition worth highlighting is the extension of password autofill to apps themselves. Presumably though, you'd have to be using iCloud keychain and not third-party apps.

Read More Add comment

Swift World: What’s new in iOS 11 — Core ML

By Manish Chauhan

Read

0 Comments

iOS 11 was announced in WWDC 2017 and available to download now. One of the most inspiring features is to leverage machine learning in different levels. The direct advantage for our developers is Core ML. In this article, I will introduce Core ML with an example to detect objects in image.

Simply speaking, there are two phases in complete machine learning development: training with large-scale data to get model and use model to predict with new input data. Core ML works in the second phase.

Here is a simple figure to depict the complete process.

I will not cover the basic knowledge in machine learning. You can find more on the Internet. Model is the most import product from machine learning algorithm and data. Core ML defines its own format for model file. So the models we get with machine learning frameworks need to be converted. Fortunately, Apple provide Core ML Tools to help us. This is not in our main topic, so please refer to its document.

There are already different models to apply to different areas like computer vision and language processing. Apple has provided several popular models including Inception v3, Places205-GoogLeNet, ResNet50 and VGG16 in its ow n format. Let’s start an example with model Inception v3 which is popular for detecting objects in image.

First please download Inception v3’s model file from https://developer.apple.com/machine-learning/. Then drag it to our new project. In Xcode 9, we can see the information about this model.

In the first part “Machine Learning Model”, there are basic information like name, author, description, etc.

Xcode will generate Swift code for this model which is shown in Model Class. Click the right arrow, we’ll get the class definitions for input, output and the model in Swift. Dive in if you want to learn more.

The inputs data and the outputs result formats are shown in the third part “Model Evaluation Parameters”. For Inception v3, the input is an image. The output is probability for each category as a dictionary and the most likely category as String.

For simplicity’s sake, we’ll use an static image. Please resize the image to 299*299 because it’s Inception v3’s default setting. Our new project is very simple. We only place an image view to preview the image and an label to show the results.

Let’s see the codes.

override func viewDidLoad() {
        super.viewDidLoad()

        let model = Inceptionv3()

        let inputImage = UIImage(named: "sample.jpg")!.cgImage!
        let pixelBuffer = getCVPixelBuffer(inputImage)

        guard let pb = pixelBuffer, let output = try? model.prediction(image: pb) else {
            fatalError("Unexpected runtime error.")
        }
        result.text = output.classLabel
    }

In the codes, we initialize an Inception v3 model. This class is generated by Xcode. In the second step, we read the input image and convert it to CVPixelBuffer with the helper function getCVPixelBuffer. At last we get the result by model’s prediction function. It’s so easy with the help of Xcode. I’ve uploaded the complete project to GitHub. Please first download Inception v3 model file from https://developer.apple.com/machine-learning/ and put in in project if you want to run it.

We only show the best result in output’s classLabel. If you want to see all probability values, print output’s classLabelProbs somewhere.

print(output.classLabelProbs)

Thanks for your time. Please click the ❤ button to get this article seen by more people.

Read More Add comment

WWDC 2017: Helping You Get This Things To Done

By Manish Chauhan

Read

0 Comments

This year at Apple’s Worldwide Developers Conference (WWDC), we saw the continued evolution of Apple’s operating systems. Pundits are often quite critical that the announcements aren’t revolutionary enough, but the annual tradition of steady improvement is perhaps their biggest competitive advantage. These easy-to-adopt yearly OS releases give consumers confidence that whatever they bought in the past few years is always going to get better, and it gives us as developers the timely insights we need to continue to build towards the future.

Highlights

There are great write-ups from our friends on what’s new in iOS 11, macOS High Sierra, tvOS 11, watchOS 4, and WWDC 2017 in general, which cover the consumer angle of Apple’s products.

Here are a couple of highlights:

The iPad continues to become a more compelling productivity device.
iMac is finally going Pro and will be getting a workstation-class upgrade later this year.
The whole lineup of Macs received the latest Intel processors.
External graphics processing enables AR and VR, and maybe even gaming.
We’re intrigued by what might be possible with the HomePod. (When do we get developer access?)
32-bit apps are being removed. It’s all 64-bit only now, so it’s time to update anything old.
We’re seeing major changes to the App Store to increase discoverability.

You can see the whole keynote on Apple’s website.

Xcode 9 Improvements

For developers, including our Nerds, the real excitement came a couple of hours later at the Platforms State of the Union. The major focus for Apple was on underlying technology and refinements, which means that the tools we work with all day every day received lots of love. If Apple delivers on the features they showed, it is not just hype: Xcode 9 might truly be the best version ever.

Performance

Let’s start with the source editor, which was rebuilt entirely in Swift with an eye toward performance. It brings support for Swift 4, giving us improvements to Strings, the Encodable protocol, keypaths and more. This delivers orders-of-magnitude-level performance improvements in everything from compilation times to build sizes.

Xcode 9 allows a relatively painless migration to Swift 3.2, and promises the upgrade to Swift 4 should be much less painful than the upgrade to Swift 3. We ran a couple of test runs, and so far that looks to be true.

Fewer Pain Points

This latest release of Xcode also removes some pain points from debugging by giving us more convenient errors, warnings and fixes. Seamless scrolling and instant jumps were a couple of highly touted features to make the interface feel much snappier. Plus, we now have the ability to intelligently highlight blocks of text—a great feature borrowed from Swift Playgrounds.

The biggest applause from the whole event was from something many developers have been begging for: refactoring.

Xcode will finally allow extracting code into new methods, renaming methods and classes, and generally keeping code more readable.
There are significant debugging improvements to help us visualize the view hierarchy.
There are also new sanitizers and compiler tools to detect mistakes.
Apple even plans to open-source the refactoring engine.

GitHub Integrations

Then, just to show they love us, Apple created deep integrations with GitHub, which might tempt a few of us away from the alternatives. Maybe.

The integration looks promising for simple usage, but advanced users are likely to stay committed to the command line in order to access the full power and danger of Git.

Productivity Gains

You can now have multiple simulators going at the same time, so testing a build across a variety of devices won’t take nearly as much time. Did I mention that you can now build, install and debug your apps wirelessly?

Xcode 9 also lays the groundwork for first-class, native support in Xcode for Swift packages, thanks to the preview version of its new build system.

Taken as a whole, these are significant productivity gains that should greatly improve your day-to-day work flow. Xcode is going to be far less painful to learn, teach and use. We can’t wait to start building with it. We’ll be kicking the tires on Xcode 9 this week, and let you know how it goes.

New APIs

Every year, we can also count on a number of new APIs and Frameworks, and this year didn’t disappoint.

A few of the highlights that we’ll be learning more about this week include:

Continued expansion of SiriKit and all new intents
Support for Drag and Drop (which looked quite easy to add)
Native Camera support for QR codes to allow deep links in your app
Metal 2 both for graphics and for advanced AI
Vision to support face, object, depth and other advanced image detection
Core ML to integrate machine learning models into your app
ARKit for making virtual objects in the real world

Anything You Can Do, You Can Do Better

In my opinion, if you can summarize all these improvements, you need only to look at the partnership between Apple, SAP and IBM. Most all of these improvements affect one key thing: helping people get things done. The tagline for the iPad is “Anything you can do, you can do better.”

Productivity seems to be Apple’s focus going forward. The presenters made a case that everything from drag and drop to advanced AI powered vision detection and augmenting reality, will enable new ways of working and perhaps even new categories of apps.

The workplace is the next great frontier for mobile transformation. You can create new workflows, improve old ones and automate mundane tasks for your customers. The amazing consumer experiences that Apple has delivered have finally pushed their way to a world where a DOS order screen can still be found.

This holds great promise for significant improvements to productivity. Apple is building the technology, SAP is unlocking the data, IBM has the servers, developers have the tools, and we all are going to get to continue to ride the wave that powerful, connected, mobile devices have brought us over the past 10 years.

We will be here at WWDC all this week and our Nerd team will have more details as we find out more about everything that Apple is announcing. Stay tuned.

Read More Add comment

Try-Catch-Throws Helps Readability

By Manish Chauhan

Read

0 Comments

Swift’s error-related syntax calls attention to possible errors through try and throws. The do/catch syntax clearly separates the happy path (no errors) from the sad path (errors):

func exampleSyncUsageOfThrows() -> Bool {
    do {
        /* happy path */
        let cookie = try ezbake()
        eat(cookie)
        return true
    } catch {
        /* sad path */
        return false
    }
}

Because throws is “viral”, you’re forced to address it one way or another, even if it’s by deciding to flip your lid when you hit an error by using the exploding try!.

No Async Syntax

Swift’s error-related syntax is great when every line of code executes one after another, synchronously. But it all goes to heck when you want to pause between steps to wait for an external event, like a timer finishing or a web server getting back to you with a response, or anything else happening asynchronously.

The Cocoa Completion Callback Pattern: Everything Is Optional

Let’s try that example again, only scheduling the cookie-baking for later, and then waiting for the cookie to cool before scarfing it:

func exampleAsyncDoesNotPlayNiceWithThrows(completion hadDinner: @escaping (Bool) -> Void) {
    ezbakeTomorrow { cookie, error in
        // hope you don't forget to check for an error first!
        // also hope you like optional unwrapping
        guard error == nil, let cookie = cookie else {
            return hadDinner(false)
        }

        wait(tillCool: cookie) { coolCookie, error in
            guard error == nil, let coolCookie = coolCookie else {
                // dog snarfed cookie?
                return hadDinner(false)
            }

            eat(coolCookie)
            hadDinner(true)
        }
    }
}

This approach of calling a completion closure with parameters for both the desired result and the failure explanation all marked optional is common across Cocoa APIs as well as third-party code. Correctly unpacking those arguments relies heavily on convention. That is to say, it relies heavily on you being very careful not to shoot yourself in the foot.

Everything Is Optional?!

Because both the success value (cookie) and the failure value (error) might not be present, both end up being optionals. That means you end up with four cases to consider, of which two should probably never happen:

Success! cookie but no error. This is unambiguous.
Failure. error but no cookie. This is similarly unambiguous.
Kind of a failure, I think? Like, maybe? Both error AND cookie. If you’re following classic Cocoa style, this gets lumped in with the success case, so that a successful run could, before ARC, leave error pointing at fabulously uninitialized data or scratch errors that didn’t happen. (As you might imagine, that convention gets messed up pretty often.)
Super-duper extra-failure. Neither error nor cookie. This is probably a bug in whatever’s giving you this output. But, alas, you still have to deal with it as a possibility.

Result: Better Async Support Through Types

Result is a popular enumeration for cleaning this up. It looks something like:

enum Result<Value> {
  case success(Value)
  case failure(Error)
}

This addresses all the weirdness with the conventional approach:

It explicitly has only two cases, so you don’t have to waste time considering the two “these are probably a bug” cases.
You can’t mess up the convention and shoot yourself in the foot. You can only get access to either the failure or the success case by design.
You can’t just ignore the error case and accidentally code for just the happy path. case exhaustiveness ensures the error is on your radar.

Just as do/catch lets you clearly separate handling a successful result from a failure, so does Result through switch/case:

func exampleAsyncLikesResult(completion hadDinner: @escaping (Bool) -> Void) {
    ezbakeTomorrow { result in
        switch result {
        case let .success(cookie):
            wait(tillCool: cookie) { result in
                switch result {
                // look ma, no optionals!
                case let .success(coolCookie):
                    eat(coolCookie)
                    hadDinner(true)

                case let .failure(_):
                    hadDinner(false)
                }
            }

        case let .failure(_):
            hadDinner(false)
        }
    }

Result: Sync, Async, It Just Works?

Result achieves the aims of do/catch/throw for async code. But it can also be used for sync code. This leads to competition between Result and throws for the synchronous case:

func exampleSyncUsageofResult() {
    return
        ezbake()
        .map({ eat($0) })
        .isSuccess
}

That’s…not so pretty. It would get even uglier if there was a sequence of possibly failing steps:

// this mess…
func exampleUglierSyncResult() {
    return
        open("some file")
        .flatMap({ write("some text", to: $0) })
        .map({ print("success!"); return $0 })
        .flatMap({ close($0) })
        .isSuccess
}
// …translates directly to this less-mess
func exampleSyncIsLessUglyWithTry() {
    do {
        let file = try open("some file")
        let stillAFile = try write("some text", to: file)
        print("success!")
        try close(stillAFile)
        return true
    } catch {
        return false
    }
}

It’s kind of easy to lose the flow in all that syntax, plus it sounds like you have a funky verbal tic with the repeated map and flatMap. You also have to keep deciding between (and distracting your reader with the distinction between) map and flatMap.

Leave Result for Async, Switch to Throws When Sync

That suggests a rule of thumb: stick with throws for synchronous code. Applying that even to mixed sync (within the body of completion callbacks) and async (did I mention completion callbacks?) code allows to play to the strengths of both throws and Result.

First, here’s a mechanical translation of the earlier exampleAsyncLikesResult function:

func exampleMechanicallyBridgingBetweenAsyncAndSync(completion hadDinner: @escaping (Bool) -> Void) {
    ezbakeTomorrow { result in
        do {
            let cookie = try result.unwrap()
            wait(tillCool: cookie) { result in
                do {
                    let coolCookie = try result.unwrap()
                    eat(coolCookie)
                    hadDinner(true)
                } catch {
                    hadDinner(false)
                }
            }
        } catch {
            hadDinner(false)
        }
    }
}

Each completion accepts a Result, but in working with it, it immediately returns to using the Swift try/throw/do/catch syntax.

try has a try? variant that allows to clean this up even more nicely. This is more like the code you’d likely write in the first place when using this style:

func exampleNicerBridgingBetweenAsyncAndSync(completion hadDinner: @escaping (Bool) -> Void) {
    ezbakeTomorrow { result in
        guard let cookie = try? result.unwrap()
            else { return hadDinner(false) }

        wait(tillCool: cookie) { result in
            guard let coolCookie = try? result.unwrap
                else { return hadDinner(false) }

            eat(coolCookie)
            hadDinner(true)
        }
    }
}

Bridging Helpers

This relies on some simple helper functions to bridge between Result and throws.

Result.unwrap() throws goes from Result to throws: The caller of an async method that delivers a Result can then use result.unwrap() to bridge back from Result into something you can try and catch. unwrap()is a throwing function that throws if it’s .failure and otherwise just returns its .success value. We saw plenty of examples earlier.
static Result.of(trying:) goes from throws to Result: The implementation of async methods can use Result.of(trying:) to wrap up the result of running a throwing closure as a Result; this helper runs its throwing closure and stuffs any caught error in .failure, and otherwise, wraps the result up in .success.
This is used to implement async functions delivering a result. Since the running example delivered a Boolean, you haven’t seen this used yet. Here’s a small example:

func youComplete(me completion: @escaping (Result<MissingPiece>) -> Void) {
    doSomethingAsync { boxOfPieces: Result<PieceBox> in
        let result = Result.of {
            let box = try boxOfPieces.unwrap()
            let piece = try findMissingPiece(in: box)
            return piece
        }
        completion(result)
    }
}

That’s a Wrap

So that’s the bottom line:

Use Result as your completion callback argument.
Within the completion body (and anywhere else you’re working synchronously), use do/catch to work with potential errors.

Read More Add comment

What is new in Swift 4

By Manish Chauhan

Read

0 Comments

What's new in Swift 4.0

Swifty encoding and decoding

We know value types are great, but we also know they interact terribly with Objective-C APIs such as NSCoding – you either need to write a shim layer or give in and use classes, both of which are unpleasant. Worse, even if you give in and switch to classes, you still need to write your encoding and decoding methods by hand, which is painful and error-prone.

Swift 4 introduces a new Codable protocol that lets you serialize and deserialize custom data types without writing any special code – and without having to worry about losing your value types. Even better, you can choose how you want the data to be serialized: you can use classic property list format or even JSON.

Yes, you read all that correctly: Swift 4 lets you serialize your custom data types to JSON without writing any special code.

Let's take a look at how beautiful this is. First, here's a custom data type and some instances of it:

struct Language: Codable {
    var name: String
    var version: Int
}

let swift = Language(name: "Swift", version: 4)
let php = Language(name: "PHP", version: 7)
let perl = Language(name: "Perl", version: 6)

ou can see I've marked the Language struct as conforming to the Codable protocol. With that one tiny addition, we can convert it to a Data representation of JSON like this:

let encoder = JSONEncoder()
if let encoded = try? encoder.encode(swift) {
    // save `encoded` somewhere
}

Swift will automatically encode all properties inside your data type – you don't need to do anything.

Now, if you're like me and have a long history of using NSCoding, you're probably somewhat doubtful: is that really all it takes, and how can we be sure it's working? Well, let's add some more code to try converting the Data object into a string so we can print it out, then decode it back into a new Language instance that we can read from:

if let encoded = try? encoder.encode(swift) {
    if let json = String(data: encoded, encoding: .utf8) {
        print(json)
    }

    let decoder = JSONDecoder()
    if let decoded = try? decoder.decode(Language.self, from: encoded) {
        print(decoded.name)
    }
}

Notice how decoding doesn't require a typecast – you provide the data type name as its first parameter, so Swift infers the return type from there.
Both JSONEncoder and its property list counterpart PropertyListEncoder have lots of options for customizing how they work: do you want compact JSON or pretty-printed JSON? Do you want to use ISO8601 dates or Unix epoch dates? Do you want to use binary property lists or XML? For more information on these and other options, see the Swift Evolution proposal for this new feature.

Multi-line string literals

Writing multi-line strings in Swift has always meant adding \n inside your strings to add line breaks wherever you want them. This doesn't look good in code, but at least it displays correctly for users. Fortunately, Swift 4 introduces new multi-line string literal syntax that lets you add line breaks freely and use quote marks without escaping, while still benefiting from functionality like string interpolation.

To start a string literal, you need to write three double quotation marks: """ then press return. You can then go ahead and write a string as long as you want, including variables and line breaks, before ending your string by pressing return then writing three more double quotation marks.
I've been specific about pressing return because string literals have two important rules: when you open a string using """ the content of your string must begin on a new line, and when you end a multi-line string using """ that must also begin on a new line.

Here it is in action:

let longString = """
When you write a string that spans multiple
lines make sure you start its content on a
line all of its own, and end it with three
quotes also on a line of their own.
Multi-line strings also let you write "quote marks"
freely inside your strings, which is great!
"""

That creates a new string with several line breaks right there in the definition – much easier to read and write.

For more information see the Swift Evolution proposal for this new feature.

Improved keypaths for key-value coding

One of the most loved features of Objective-C is its ability to reference a property dynamically rather than directly – that is, to be able to say "given object X, here is the property I'd like to read" without actually reading it. These references, called keypaths, are distinct from direct property accesses because they don't actually read or write the value, they just stash it away for use later on.

If you've never used keypaths before, let me show you an analogy of how they work using regular Swift methods. We're going to define a struct called Starship and a struct called Crew, then create one instance of each:

// an example struct
struct Crew {
    var name: String
    var rank: String
}

// another example struct, this time with a method
struct Starship {
    var name: String
    var maxWarp: Double
    var captain: Crew

    func goToMaximumWarp() {
        print("\(name) is now travelling at warp \(maxWarp)")
    }
}

// create instances of those two structs
let janeway = Crew(name: "Kathryn Janeway", rank: "Captain")
let voyager = Starship(name: "Voyager", maxWarp: 9.975, captain: janeway)

// grab a reference to the `goToMaximumWarp()` method
let enterWarp = voyager.goToMaximumWarp

// call that reference
enterWarp()

Because functions are first-class types in Swift, the last two lines are able to create a reference to the goToMaximumWarp() method called enterWarp, then call that later on whenever we want to. The problem is, you can't do the same thing for properties – you can't say "create a reference to the captain's name property that I can check when the inevitable mutiny happens," because Swift will just read the property directly and you'll just get its original value.

This is fixed with keypaths: they are uninvoked references to properties just like our enterWarp() code. If you invoke the reference now you get the current value, but if you invoke the reference later you get the latest value. You can dig through any number of properties, and Swift uses its type inference to ensure you get the correct type back.

The Swift Evolution community spent quite a while discussing the correct syntax for keypaths because it needed to be something visually different from other Swift code, and the syntax they ended up with uses backslashes: \Starship.name, \Starship.maxWarp, and \Starship.captain.name. You can assign those two to a variable then use them whenever you want, on any Starship instance. For example:

let nameKeyPath = \Starship.name

let maxWarpKeyPath = \Starship.maxWarp
let captainName = \Starship.captain.name

let starshipName = voyager[keyPath: nameKeyPath]

let starshipMaxWarp = voyager[keyPath: maxWarpKeyPath]

let starshipCaptain = voyager[keyPath: captainName]

That will make starshipName a string and starshipMaxWarp a double, because Swift is able to infer the types correctly. The third example there even goes into the property of a property, and Swift still figures it out correctly.

Future plans for this include being able to access array indexes and to create keypaths from strings at runtime – for more information see the Swift Evolution proposal for this new feature.

Intermission

If you're enjoying this article, you might like my free Natural Swift video. It gives you 75 minutes of hands-on coding that teaches functional programming, protocol-oriented programming, and value types, and you can download it for free with no obligation or catches – just click here.

And now back to your regularly scheduled broadcast…

Improved dictionary functionality

One of the most intriguing proposals for Swift 4 was to add some new functionality to dictionaries to make them more powerful, and also to make them behave more like you would expect in certain situations.

Let's start with a simple example: filtering dictionaries in Swift 3 does not return a new dictionary. Instead, it returns an array of tuples with key/value labels.

For example:

let cities = ["Shanghai": 24_256_800, "Karachi": 23_500_000, "Beijing": 21_516_000, "Seoul": 9_995_000];
let massiveCities = cities.filter { $0.value > 10_000_000 }

After that code runs you can't read massiveCities["Shanghai"] because it is no longer a dictionary. Instead, you need to use massiveCities[0].value, which isn't great.

As of Swift 4 this behaves more like you would expect: you get back a new dictionary. Obviously this will break any existing code that relies on the tuple-array return type.

Similarly, the map() method on dictionaries never quite worked the way many people hoped: you got a key-value tuple passed in, and could return a single value to be added to an array. For example:
let populations = cities.map { $0.value * 2 }

That hasn't changed in Swift 4, but there is a new method called mapValues() that is going to be much more useful because it lets you transform the values and place them back into a dictionary using the original keys.

For example, this code will round and stringify all city populations, then put them back into a new dictionary with the same keys of Shanghai, Karachi, and Seoul:

let roundedCities = cities.mapValues { "\($0 / 1_000_000) million people" }

(In case you were wondering, it's not safe to map dictionary keys because you might create duplicates by accident.)

Easily my favorite new dictionary addition is a grouping initializer, which converts a sequence into a dictionary of sequences that are grouped by whatever you want. Continuing our cities example, we could use cities.keys to get back an array of city names, then group them by their first letter, like this:

let groupedCities = Dictionary(grouping: cities.keys) { $0.characters.first! }
print(groupedCities)

That will output the following:

["B": ["Beijing"], "S": ["Shanghai", "Seoul"], "K": ["Karachi"]]

Alternatively, we could group the cities based on the length of their names like this:

let groupedCities = Dictionary(grouping: cities.keys) { $0.count }
print(groupedCities)

That will output the following:

[5: ["Seoul"], 7: ["Karachi", "Beijing"], 8: ["Shanghai"]] Finally, it's now possible to access a dictionary key and provide a default value to use if the key is missing:

let person = ["name": "Taylor", "city": "Nashville"]
let name = person["name", default: "Anonymous"]

Now, any experienced developer will probably argue that's better written using nil coalescing, and I agree. You could write this line instead using the current version of Swift:

let name = person["name"] ?? "Anonymous"

However, that doesn't work when you're modifying the dictionary value rather than just reading it. You can't modify a dictionary value in place because accessing its key returns an optional – the key might not exist, after all. With Swift 4's default dictionary values you can write much more succinct code, such as this:

var favoriteTVShows = ["Red Dwarf", "Blackadder", "Fawlty Towers", "Red Dwarf"]
var favoriteCounts = [String: Int]()

for show in favoriteTVShows {
    favoriteCounts[show, default: 0] += 1
}

That loops over every string in favoriteTVShows, and uses a dictionary called favoriteCounts to keep track of how often each item appears. We can modify the dictionary in one line of code because we know it will always have a value: either the default value of 0, or some higher number based on previous counting.

For more information see the Swift Evolution proposal for these new features.

Strings are collections again!

This is a small change, but one guaranteed to make a lot of people happy: strings are collections again. This means you can reverse them, loop over them character-by-character, map() and flatMap() them, and more. For example:

let quote = "It is a truth universally acknowledged that new Swift versions bring new features."

let reversed = quote.reversed()

for letter in quote {
    print(letter)
}

This change was introduced as part of a broad set of amendments called the String Manifesto.

One-sided ranges

Last but not least, Swift 4 introduces Python-like one-sided collection slicing, where the missing side is automatically inferred to be the start or end of the collection. This has no effect on existing code because it's a new use for the existing operator, so you don't need to worry about potential breakage.
Here's an example:

let characters = ["Dr Horrible", "Captain Hammer", "Penny", "Bad Horse", "Moist"]
let bigParts = characters[..<3]

let smallParts = characters[3...]
print(bigParts)
print(smallParts)

That code will print out
["Dr Horrible", "Captain Hammer", "Penny"] then ["Bad Horse", "Moist"].

For more information see the Swift Evolution proposal for this new feature.

Read More Add comment

Subscribe to: Posts ( Atom )

Core ML

What models does Core ML support?

Limitations

A quick demo app

How fast is it?

Vision

Metal Performance Shaders

Odds and ends

Here’s how

Conclusions

Core ML in iOS 11 Provides Machine Learning Models

ARKit in iOS 11 Offers Native Augmented Reality

iOS 11 Further Refines iOS Visual Design Language

New iOS 11 Product Page in App Store

Start In-App Purchases From the App Store

Use iOS 11 Business Chat to Better Engage Users

Take Another Look at iMessage Apps in iOS 11

iOS 11 Phased Releases for App Store Updates

Drag and Drop, Browse Files, and App Password Autofill

Highlights

Xcode 9 Improvements

Performance

Fewer Pain Points

GitHub Integrations

Productivity Gains

New APIs

Anything You Can Do, You Can Do Better

No Async Syntax

The Cocoa Completion Callback Pattern: Everything Is Optional

Everything Is Optional?!

Result: Better Async Support Through Types

Result: Sync, Async, It Just Works?

Leave Result for Async, Switch to Throws When Sync

Bridging Helpers

That’s a Wrap

What's new in Swift 4.0

Swifty encoding and decoding

Multi-line string literals

Improved keypaths for key-value coding

Intermission

Improved dictionary functionality

Strings are collections again!

One-sided ranges

Recent Posts

Facebook

About Me

Followers

Archive

Search This Blog

Archive

Labels

Blog Post

Video Of Day

Like This Theme

Author Info