Apple's new developer resources for iOS 9, OS X El Capitan promise next-level apps and services

Posted:
in General Discussion edited June 2015
At is annual World Wide Developers Conference on Monday, Apple announced a host of new technologies designed to help developers offer improved user experiences over the entire Apple product line.




During WWDC's keynote presentation, a number of new developer resources were highlighted that will soon shape app development and the products they support.

HomeKit




Last year, Apple introduced a new framework called "HomeKit" which was designed to enable a seamless way for smart devices to communicate with each other. Instead of a companion app to access house data in the framework, Apple is relying on its Siri virtual assistant.

Briefly mentioned at WWDC, Siri integration lets users create a "scenes" for HomeKit-enabled appliances. By issuing voice commands through Siri, users are able to control connected devices within the home, including recently-announced HomeKit-compatible hardware from Insteon, Lutron, iHome and Philips Hue lighting.

Only a few third-party manufacturers are showing initial support, perhaps due to Apple's strict requirements for program entry that call for hardware encryption, but SVP of Software Engineering Craig Federighi said consumers will soon see HomeKit-compatible window shades, thermostats, smoke detectors, carbon monoxide sensors and more.

Metal

Announced last year, Metal is a base-level framework or iOS that improves graphics performance up to 50 percent. As reported previously, Apple announced Metal for Mac alongside the introduction of OS X 10.11 El Capitan.

Metal combines OpenCL and OpenGL into a single API, allowing developers an extremely flexible and powerful tool for app creation. Further, the framework draws on the same data resources for both graphics and compute operations, while enabling multi-threading. The end result is a highly efficient interface that gets developers as close to GPU -- the "metal" -- as possible without jumping through programming hoops.

With Metal, games such as Epic's Fortnite, which was demoed during the keynote, can now be developed for Mac with the same high-performance rendering engine that's available on iOS.

Search




In iOS 9, Apple's new Search API links search functionality in Spotlight with in-app content. When developers implement Search, they can make app content available for discovery by Search and Siri.

This "deep-linking" is similar in functionality to the "Now on Tap" feature announced at Google I/O. Search also connects iOS with Web content. Implementing the code necessary for discoverability should take about an hour and requires no prior search programming experience as it is handled with standard object models.

Swift 2.0

Perhaps the biggest surprise for developers on Monday was the announcement that Swift would enter its 2.0 iteration as an open source programming language.

Swift is the replacement for Objective-C and was introduced last year as a safer, faster and more efficient language for building everything from simple apps to complete operating systems. Version 2.0 brings many developer friendly changes such as:
  • Better error handling
  • Syntax improvements via new control logic such as do, guard, defer, and repeat statements.
  • Faster compiler
  • New fix-it statements
  • Support for Markdown syntax
  • Protocol extensions and default implementations
iOS 9 System & App Support




iOS 8 was infamous for the amount of space required for an install, which prevented users from keeping their devices up to date. As was announced in the keynote, with iOS 9, Apple has significantly reduced the size of the iOS download by over 70 percent. The less storage space required, the more accessible iOS 9 is to users.

Apple has also made significant efforts to optimize app submissions, storage, and downloads. This endeavor is known as App Thinning, and it uses three new technologies: App Slicing, On Demand Resources, and Bitcode.




Current iOS apps require a wide-range of assets to be grouped together in one bundle in order to run on multiple devices. App Slicing will allow the app to only use those assets needed for a particular device configuration. The App Store will select only those assets a user needs for his/her particular device from the entire range of assets in the app bundle.

Sometimes apps have resources that aren't needed all the time. ODR will enable apps to offload things like tutorials onto Apple's servers and then download them when the app actually needs it. This will allow app downloads to be significantly smaller.

Finally, Bitcode is an LLVM intermediate representation of an app's binary. When the app is submitted to the App Store, Bitcode will automatically analyze the code via the App Store to ensure that it is optimized for software updates. This will help to "future proof" apps so they don't have to be resubmitted.

All watchOS apps must use Bitcode and iOS apps will have Bitcode temporarily enabled by default. However, future iOS development will require Bitcode for all app submissions.

Comments

  • Reply 1 of 12

    On Demand Resources sounds like one that may be iffy if not managed right (think data plan), but I'm very happy for the App Slicing plan in general. I've still got a 16GB iPad and more space is always appreciated.

     

    It'd also be nice if iOS 9 also reduced the overall OS footprint, even if it were only 100MB.

  • Reply 2 of 12
    Whoa!! I wonder how many apps I can get on my old iPad under the the new "thinning" method. I'm often going through and sending apps to the cloud so I can add something new. My next iPad will definitely have more storage, but this change will give me another year with "old reliable."

    Also, this may be the first time that a computer device got faster for me the longer I owned it.
  • Reply 3 of 12
    asciiascii Posts: 5,941member
    Quote:

    Originally Posted by TheWhiteFalcon View Post

     

    On Demand Resources sounds like one that may be iffy if not managed right (think data plan), but I'm very happy for the App Slicing plan in general. I've still got a 16GB iPad and more space is always appreciated.


    Yeah, Bitcode and App thinning are good ideas but on demand resources can potentially give a bad user experience, and user experience should be put ahead of all other considerations, therefore it should not have been implemented.

     

    There's actually a lot of amazing new stuff for game development they're announcing (not just Metal for Mac) it's in the later half of the Platforms State of the Union talk.

  • Reply 4 of 12
    nagrommenagromme Posts: 2,834member
    Quote:

    Originally Posted by ascii View Post

     

    Yeah, Bitcode and App thinning are good ideas but on demand resources can potentially give a bad user experience, and user experience should be put ahead of all other considerations, therefore it should not have been implemented.

     

    There's actually a lot of amazing new stuff for game development they're announcing (not just Metal for Mac) it's in the later half of the Platforms State of the Union talk.




    Developers are not forced to use ODR—I'm glad it's been implemented, and if developers use it when they shouldn't (like any OS feature) that's on them. Minus one star :) Plenty of games and apps already use on-demand data for tutorials: as streaming videos. Keep them small is all I ask, and let the user enable/disable ODR-over-cell data.

  • Reply 5 of 12
    ascii wrote: »
    <span style="line-height:1.4em;">Yeah, Bitcode and App thinning are good ideas but on demand resources can potentially give a bad user experience, and user experience should be put ahead of all other considerations, therefore it should not have been implemented.</span>


    1. "potentially" - So, does it?

    2. "should be put ahead of all" - Over reliability? Over functionality? Over practicality? Over everything?

    3. "should not" - Are you saying Apple just thought it might be a good idea and slapped it in without any testing to ensure that apps still carry on working as intended? Do you know of an app download/usage scenario that Apple's engineers all missed? Have you some inside knowledge to which we're not privy?
  • Reply 6 of 12
    asciiascii Posts: 5,941member
    Quote:

    Originally Posted by nagromme View Post

     



    Developers are not forced to use ODR—I'm glad it's been implemented, and if developers use it when they shouldn't (like any OS feature) that's on them. Minus one star :) Plenty of games and apps already use on-demand data for tutorials: as streaming videos. Keep them small is all I ask, and let the user enable/disable ODR-over-cell data.


    It won't necessarily be on them though. If it gets widespread enough adoption (which is more likely when something is a system framework and when Apple handles the hosting), then the platform as a whole could get a reputation/feeling of "always loading."

     

    One (big) thing they changed in watchOS 2 vs watchOS 1 is that the app is now hosted natively on the Watch, instead of the app being hosted on the phone and the Watch just acting as a display server. I remember several of the big review sites complain of loading delays that were mostly likely caused by this architecture. And now they have fixed it which is great, but they clearly didn't learn their lesson, since they are introducing ODR on the phone, which has the same potential problems.

  • Reply 7 of 12
    asciiascii Posts: 5,941member
    Quote:
    Originally Posted by KiltedGreen View Post





    1. "potentially" - So, does it?

     

    It potentially does, it depends on how the individual app developer implements it.

     

    Quote:
    Originally Posted by KiltedGreen View Post



    2. "should be put ahead of all" - Over reliability? Over functionality? Over practicality? Over everything?

    Those are all aspects of the user-experience surely? In general, I think where there are tradeoffs to be made between ease for the user and ease for the developer you should favour the user and put the weight on the developer's shoulders.

    Quote:

    Originally Posted by KiltedGreen View Post



    3. "should not" - Are you saying Apple just thought it might be a good idea and slapped it in without any testing to ensure that apps still carry on working as intended? Do you know of an app download/usage scenario that Apple's engineers all missed? Have you some inside knowledge to which we're not privy?

     

    I don't think you understand the technology in question. It's basically an API and some Apple provided hosting to let apps download things in the background. For example if you have a multi-level game, instead of all the levels being included when you download the app, only level one is included, and when the app detects you getting near the end of level 1, it starts downloading level 2 in the background from Apple's servers.

     

    So you see, it's not a question of Apple testing it thoroughly enough or not. It could be fully tested and fully functional and still give a bad user experience. e.g. you are playing a game on the tube and level 2 is coming up but there's no mobile network available so your gaming has to stop. Or you download an app and are unaware of this feature, so it successfully download level 2 but uses up your whole data quota for the month.

     

    So, just makes apps download fully when you buy them, or when you do an IAP. It's worked for ages and it works well because the user knows when downloading is happening so they expect a delay and can be near WiFi. Instead of getting unexpected delays and quota usage.

  • Reply 8 of 12
    tmaytmay Posts: 3,662member
    Quote:

    Originally Posted by ascii View Post

     

     

    It potentially does, it depends on how the individual app developer implements it.

     

    Those are all aspects of the user-experience surely? In general, I think where there are tradeoffs to be made between ease for the user and ease for the developer you should favour the user and put the weight on the developer's shoulders.

     

    I don't think you understand the technology in question. It's basically an API and some Apple provided hosting to let apps download things in the background. For example if you have a multi-level game, instead of all the levels being included when you download the app, only level one is included, and when the app detects you getting near the end of level 1, it starts downloading level 2 in the background from Apple's servers.

     

    So you see, it's not a question of Apple testing it thoroughly enough or not. It could be fully tested and fully functional and still give a bad user experience. e.g. you are playing a game on the tube and level 2 is coming up but there's no mobile network available so your gaming has to stop. Or you download an app and are unaware of this feature, so it successfully download level 2 but uses up your whole data quota for the month.

     

    So, just makes apps download fully when you buy them, or when you do an IAP. It's worked for ages and it works well because the user knows when downloading is happening so they expect a delay and can be near WiFi. Instead of getting unexpected delays and quota usage.


    Easy. Make it a setting. Let the user decide how much to download initially.

     

    It's a very granular approach, and very appropriate to implement. I favor this approach.

  • Reply 9 of 12
    Quote:

    Originally Posted by ascii View Post

     

    So you see, it's not a question of Apple testing it thoroughly enough or not. It could be fully tested and fully functional and still give a bad user experience. e.g. you are playing a game on the tube and level 2 is coming up but there's no mobile network available so your gaming has to stop. Or you download an app and are unaware of this feature, so it successfully download level 2 but uses up your whole data quota for the month.

     

    So, just makes apps download fully when you buy them, or when you do an IAP. It's worked for ages and it works well because the user knows when downloading is happening so they expect a delay and can be near WiFi. Instead of getting unexpected delays and quota usage.


     

    Good points. However, having seen all the sync scenarios Apple proposed for iCloud in the developer documentation, I'd expect that all those situations you've suggested are exactly the kind of thing that they would have designed it to deal with. Surely, a game with level 2 stored in the cloud when you're just reaching the end of level 1 and then go into a WiFi-free zone would be the most obvious problem that the Apple's engineers would have to address would it not?

     

    Saying that the system "has worked for ages" is not really the case, except in that there has been no alternative. I have games on my iOS devices where I've completed many previous levels, won't revisit them and yet they are taking up space on my device and so they are a) Restricting scratch space for apps such as Pixelmator (which wants over 1GB free) and b) Limiting the size of any other apps I could otherwise install.

     

    Obviously Apple would have to get it right but it's surely worth exploring because if it's done correctly then there is considerable benefit for users.

  • Reply 10 of 12
    frantisekfrantisek Posts: 441member
    Apple is on the way to single OS or highly unified OSs independent of CPU architecture.
  • Reply 11 of 12
    tmay wrote: »
    Easy. Make it a setting. Let the user decide how much to download initially.

    It's a very granular approach, and very appropriate to implement. I favor this approach.

    I disagree. The user doesn't necessarily know what they are being asked to decide. Especially if it is a child being asked. Memory management of this kind is best invisible to the user. Additionally, levels are something which are often purchased, so one isn't sure if they are being asked to purchase or just download. Bad, bad, bad!!!
  • Reply 12 of 12
    frantisek wrote: »
    Apple is on the way to single OS or highly unified OSs independent of CPU architecture.

    Nope, nope, and nope. Apple will not evolve both OS's into a single OS. The touch interface and the mouse interface may come to be more similar, which will make switching from using the iPad to the Mac easier and more familiar, but they will remain two different OS's. It is possible that the Mac OS may die out at some time, but that will be because Apple only serving the mobile user, which is where most of the growth is at.

    That may never happen as the laptop computer is where the Mac growth is at. Apple's laptops are getting more powerful and more independent of the recharger, so Apple is poised to go either way with the best form factor vs MS Surface which is more of a platypus; which is NOT a good duck AND not a good muskrat...
Sign In or Register to comment.