New features of iOS 9 SDK that developers need to know

[[146244]]

Flowers look the same every year, but people are different every year. This year's WWDC is as lively as ever, but because I have to take care of my newborn baby and the baby's mother at home, I can only watch this grand gathering of Apple developers at home in my home theater.

Life is endless, learning is endless. As in the past few years, I will continue to write about what I find interesting and what I focus on and learn in WWDC and the new SDK. Now looking back at what I wrote in the past few years, I feel more and more that I was really silly and cute in my youth. However, the growth trajectory along the way is very obvious, and I hope I can continue this journey calmly.

Enough of the pretentiousness, it’s time to get down to business. Let’s take a look at some of the things I think developers need to pay attention to in this year’s WWDC.

Overview

The biggest challenges and most urgent tasks facing developers in the iOS 9 era may be two aspects. The first is how to use and adapt to the new split-screen multitasking feature of iPad, and the second is how to face and use watchOS 2 to build native watch apps. Other new topics are basically the derivation and extension of existing frameworks, including the expansion from unit testing to UI testing, how to further occupy and use the system's notification center and search page, and the use of Swift 2.

It can be said that after two consecutive heavyweight changes and updates in iOS 7 and iOS 8, iOS 9 SDK has become somewhat relaxed and calm for ordinary app developers. The new SDK has not undergone any major changes in API and overall design. Developers can also take this opportunity to take a breather, and as soon as possible further familiarize themselves with and at least transition to using the content of iOS 8 SDK to build their own apps (such as trying to use Size Class and Presentation Controller, etc.), improve their professional skills and the level of the apps they make as soon as possible, and ensure that they can keep up with the rolling Apple wheel. This should be the main task of Cocoa developers this year.

Multitasking

This can be said to be the biggest selling point of iOS 9. The multitasking feature, especially split-screen multitasking, makes the iPad truly like a personal computer capable of handling heavy tasks. Although jailbreak plug-ins have long been available to allow iPads to run multiple programs at the same time, Apple was very cautious and did not implement this feature on its most powerful mobile device until 2015. Multitasking in iOS 9 is divided into three forms, namely, the temporary Slide Over, the Picture in Picture mode for video playback, and the real Split View for using two apps at the same time. Currently, only the latest iPad Air 2 supports the Split View mode among the devices that can run iOS 9, but I believe that with the update of devices, the use of Split View is likely to become a mainstream way for people to use iPads in daily life, so it is a must for developers to prepare in advance.

Although it may seem complicated to support multitasking views at first glance, it is actually quite simple if you have followed Apple’s lead in the past year. Slide-overlay and split-view apps will use the Compact Width and Regular Height settings in the Size Class introduced in iOS 8, combined with AutoLayout for layout. In other words, if your app was previously compatible with both iPhone and iPad, and has used Size Class for layout, you basically don’t need to do anything extra to support the multitasking view of iOS 9. But if you haven’t used these technologies yet, you may need to migrate to this layout method as soon as possible to fully support it.

The picture-in-picture mode of the video app is relatively simple. If you use AVPlayerViewController or AVPlayerLayer to play videos, you don’t need to do anything to support it. But if you previously chose MPMoviePlayerController or MPMoviePlayerViewController, you may also need to migrate to the AVKit framework as soon as possible, because Media Player will be marked as deprecated in iOS 9 and will no longer be maintained.

Related topic notes

iOS 9 Multitasking Split Screen Key Points

watchOS 2

In the new watchOS 2, the architecture of the Watch App has undergone a major change. In the new system, the extension of the Watch App will not exist in the iPhone as it does now, but will be installed directly in the watch. The Apple Watch has evolved from a simple interface display to a device that can execute developer code. Thanks to this, developers can also access information such as the digital crown and (although they are only very basic access, but better than nothing) heart rate count in the extension. Although there has been some progress, Apple is still very cautious in its attitude in watchOS 2, which may have a lot to do with the device limitations of the first generation of Apple Watch, so the power and performance space left for app developers is not very broad. But compared to the current WatchKit, being able to run without the iPhone is itself a remarkable improvement. And in order to communicate with the iPhone, the new framework WatchConnectivity has now been added. We have enough reason to look forward to the performance of Apple Watch and WatchKit in the next two or three years.

Related topic notes

Develop a simple watchOS 2 app in 30 minutes

UI Test

In the development field, testing has always been the key to ensuring product quality. Since Xcode 4, the status of testing in app development has been rising year by year. From the introduction of the XCT framework, to the test target becoming the default when creating a new project, to the asynchronous code test and performance test added last year. It can be said that the test framework that comes with Xcode can now meet most of the unit testing needs.

But this is not enough. Developing an iOS app has always been a job that focuses more on UI and user experience. Simple unit testing can easily ensure the correctness of the model layer, but it is difficult to make a difference in the UI. How to write UI tests for an app has always been one of the difficult problems in the Cocoa community. In the past, there were brain-opening solutions such as KIF, Automating, and even FBSnapshotTestCase. This year, Apple has provided a more attractive option, which is a series of XCUITest tools that come with Xcode.

Similar to most existing UI testing tools, XCUI uses Accessibility tags to identify views, but because it is Apple's own product, it can automatically record your operation process, so you only need to write the final verification part, which is much more convenient than other UI testing tools.

Swift 2

After a year of improvement and progress, Swift can now be used well for app development. I have been using Swift as the main language for my daily work for more than half a year. In the past six months, I have felt that I am getting more comfortable writing. The main change in Swift 2 is the change in error handling. Apple has changed from the traditional Cocoa error handling method based on NSError to the throw catch exception handling mechanism. This change can indeed make the program safer, and the newly added ErrorType also unifies the error description well. However, after a day or two of actual contact, I feel that the syntax is more than the original processing code. It may be caused by the long-term habit of using NSError. I have not yet been able to fully accept the exception mechanism in Swift 2. However, this time Apple has done a relatively radical thing, replacing all errors in the Cocoa API with throw. So whether you are willing or not, the transition to exception handling is something that Swift developers must face.

In addition, Apple has added some new control flow keywords such as guard and defer, which are also very practical features in some other languages, making Swift writing simpler and more fluent to read. In order to solve the problem of availability of different SDKs at runtime, Apple also added available blocks in Swift 2. In the past, we needed to remember the availability of APIs ourselves and do this by checking the system version and comparing them. Now with available detection, the compiler will check those API calls that may have version mismatches, and the security of app development is further guaranteed. In order to make the entire SDK more suitable for Swift's syntax habits, Apple finally introduced generics in Objective-C. This seems to be an enhancement of Objective-C, but in fact it is really paving the way for Swift to unify Apple development. With Objective-C generics, using Swift to access Cocoa APIs will basically no longer get the AnyObject type, which makes Swift's security features a step up.

Finally, there is the news of Swift 2 open source. Swift's compiler and standard library will be open source at the end of this year. It may not bring any big changes to the average app developer, but it does mean that Swift will transform from a dedicated language for app production to a general language. The easiest thing to think of is backend development based on Swift. Maybe we can feel the power of Swift's full stack before we see Javascript dominate the world?

App Thinning

I work in Japan, and because everyone here has a monthly data plan and the data traffic is overflowing, basically no one cares about the size of the app, it's just the difference between 5 seconds and 10 seconds to download. But when communicating with domestic colleagues, I found that domestic app development has almost harsh requirements on size. Because iOS apps now include both 32-bit and 64-bit slices for backward compatibility. In addition, in terms of image resources, 1x 2x 3x images are available (well, 1x should not be needed now). When users use the app, because the device is specific, they actually only need one set of resources. But now when purchasing and downloading, the entire app package is downloaded.

Apple finally realized how stupid this was, and in iOS 9, you can finally select only the content you need (Slicing) to download. This is a great benefit to users, because you can save a lot of data by just upgrading to iOS 9. For developers, there is not much to do, just use the asset catalog to manage the material tags 2x 3x.

Another way to slim down your app is to submit Bitcode to Apple instead of the final binary. Bitcode is the intermediate code of LLVM. When the compiler is updated, Apple can use the Bitcode you submitted previously for optimization, so you don't have to submit your app again after the compiler is updated, and you can still enjoy the benefits of compiler improvements. Bitcode support is enabled by default in new projects, and you don't need to turn it off unless there is a special reason.

Finally, there are resources loaded on demand. This may be used more in games. You can use tags to organize resources such as images or sounds, such as marking them as level 1, level 2, etc. Then you only need to download the content of level 1 at the beginning, and then download level 2 during the game. Or you can use this to postpone the download of resource files that require in-app purchases. This is a very common optimization method in some large games, and it can now be easily used in iOS 9.

Artificial Intelligence and Search APIs

If there is anything else that impressed me deeply in this WWDC Keynote, I would vote for a smarter mobile assistant. Although it seems very basic, such as playing your favorite music when plugging in headphones, recommending people you might contact and apps to open, etc., it is indeed a meaningful step. The current Siri is just a question-and-answer system. If the context is interrupted, "she" can't even remember what the previous two sentences said. A secretary who can't remember the boss's habits is definitely not a good nurse, and Apple is making the iPhone work towards this. The good news is that we probably don't have to worry about encountering a machine that deliberately fails the Turing test for the time being, so there is still a lot of room for artificial intelligence.

The search API actually gives the app another possible entry point. Some users will use the search interface very frequently, which is a great opportunity to showcase your app and increase the open rate. If the app type is suitable, this is a very worthwhile additional feature.

Game related

Game apps are the easiest to cross-platform because there is no huge gap in user experience on different mobile platforms - after all, no developer can ignore the market share of Android. This is also the reason why Apple's own game frameworks such as SpriteKit and SceneKit have been tepid. Rather than being limited to the Apple platform, more developers choose cross-platform solutions such as Unity or Cocos2d-x. However, this year Apple continued to strengthen its support for game development tools, including the GameplayKit framework for state machine maintenance and pathfinding, the ReplayKit framework for recording and replaying game processes, and the Model I/O framework for physical modeling.

These are actually some of the algorithms and tools that are already mature in the game industry that are added to Apple's game development system, saving developers a lot of time. For individual developers to make their own games, Apple's tools provide a relatively low threshold and are easy to use. However, in an era where most game development requires cross-platform, it always feels that whether Apple's system can continue smoothly needs further observation.

other

HomeKit, CloudKit, HealthKit, etc. There are all kinds of frameworks. If it is an iOS-only app, using CloudKit for BaaS may be a good choice, but it also faces the risk of difficulty in sharing data across platforms in the future. Several other frameworks are relatively professional, and most of them require hardware support. In fact, it has been said that smart hardware is the next hot spot, but at least so far it has not made a big noise, and more have entered the cheap competition (you know what bracelets are like). We can only look forward to the subsequent performance of these devices.

Finally, there is a benefit for those who are just starting out or planning to get involved in Apple development. Now you can deploy apps to your own devices without joining the paid developer program, which previously required you to join the developer program at least $99 per year. This can be said to have further lowered the threshold for Apple development.

Summarize

As mentioned above, for developers, this year's WWDC did not bring disruptive changes like those in 2013 and 2014. Most of the changes were enhancements to existing features and enhancements to the development tool chain. This year can be said to be a good opportunity for Cocoa developers to accumulate previous knowledge and improve their skills. Now WWDC 15 is still in full swing. If you plan to embrace the changes in the new SDK as soon as possible, please do not hesitate to visit Apple's developer website directly to find and watch the topics you are interested in.

10 Reasons Why Apple iOS 9 Is Worth Upgrading http://www.linuxidc.com/Linux/2015-06/118595.htm

Detailed introduction of iOS: Please click here