BJ Homer

• No more gradient toolbar buttons (as found in Finder, Safari, etc.)
  I would be very surprised if we don’t see these transition to a more flat style.  We saw the same sort of transition from Xcode 4.6 to Xcode 5. Expect that gradient buttons will be rare, especially in toolbars. I don’t think the new style will look just like Xcode 5—I expect we’re in for more of a change than that—but I’d be surprised if this isn’t part of it.

Finder in OS X 10.9

Xcode 4.6

Xcode 5

• Dock changes
  The Dock seems like an obvious target for changes. Currently, the dock serves as a quick launcher, an app switcher, a container for minimized windows, a home for “Stacks,” and the only visible location of the Trash icon. It’s an unfocused mess.

  “Multiple, more-focused docks” is obviously not the right answer. They might remove running apps and just expect users to switch between them using Mission Control or by clicking on the window, but that just seems like it’s removing functionality without any user benefit. Maybe they make it only show apps that currently have windows open? But then the quick-launch functionality is gone.

  So what does this all mean for the Dock? I’m not sure, really. But I think it’s ripe for change; I’ll be really surprised if the Dock stays exactly how it is right now.
   

• Open/Closed apps
  I expect Apple to continue reducing the distinction between “running” and “non-running” apps. Recent features like Mission Control suggest that Apple feels managing visible windows is more important than managing apps. (See also the trend toward integrating “Inspector” panels into the main window.) There’s already an option to remove the indicator lights for open applications in the Dock, and in past years, Apple has indicated that the Automatic Termination feature will become more and more prominent.

  The iOS app management model is an inspiration for Apple, I believe. iOS users generally don’t worry about whether an app is “running” or not; they just know that if they can see it, they can use it. Obviously, on a desktop system with multiple windows visible at the same time, things are more complex. But if things are already getting reshuffled visually, expect more movement in this direction.
   

• Menu Bar
  The global menu bar is one of the hallmarks of OS X. Windows migrants protest its disconnection from the window content. Mac veterans point out its consistent location and reliability.

  More and more, I feel that most users will never find features available only through the menu bar. Right-click contextual menus are far more accessible to users than the global menu bar. Increasingly, the standard File menu is more about managing windows and tabs than about files. The View menu usually manages the state of the window, and the Window menu is just a list of app windows that most people never use.

  Honestly, I don’t really think we’ll see significant changes to the menu bar itself. Changing it would break too many assumptions from existing apps. But I wouldn’t be surprised if the built-in apps start abandoning the traditional File, Edit, View, Window, Help setup for a more user-friendly structure.
    

• Better access to iCloud documents
  Currently, if an app saves a file in iCloud, that file is really only available from within that app. It shows up in Finder’s All My Files view, but that list is so huge that it’s mostly unmanageable. I’d love for Finder to have a view of files organized by app. Essentially, each app would be a “folder” for its documents.
   
• Siri
  We’ll probably see Siri show up on OS X at some point. Maybe it will be this year? It’s possible, but I’m not counting on it. If it shows up, I’ll consider it a nice surprise.
   
• Clock app
  I said it jokingly on Twitter, but it actually wouldn’t surprise me if OS X included an iPad-like Clock app. Stopwatch included.

OS X is rumored to be the star of WWDC this year, but iOS will certainly have some new features too. The WWDC app lists 99 sessions with content relevant to iOS, and only 78 relevant to OS X. Some of this is surely just a reflection of the prominence of iOS in Apple’s developer base, but it would be foolish to assume that iOS won’t be getting anything interesting this year. 

• App Services via Remote View Controllers 
  Back in October 2012, Ole Beggeman did some great investigative work on remote view controllers, used internally since iOS 6. The basic idea is that some portion of your app’s interface is actually provided by a separate process. This is currently used for the Mail composition controller, for example; the pixels you see are actually generated in a separate app and then drawn into your app. Touches in that region are forwarded on to that helper app, such that everything appears to the user as if it all originated in the same app.

  Remote view controllers could resolve one of the longest-standing complaints about iOS—that apps are too “silo-ed off” from each other. Apps could instead provide interfaces to each other as “Services”. Imagine if the Dropbox app could an interface for other apps to upload or download documents from within their app, without embedding a Dropbox SDK. Imagine if your university’s LMS app could present a file-picking interface from Pages, and submit it as a homework submission for you. Or imagine if you could turn your Pages document as a homework submission from within the Pages app.

  This is the kind of thing that app services would allow. Of course, you’d have to have some programmatic way to discover available services and their purpose. Pages certainly isn’t going to build in custom support for your university’s LMS app. One approach might be for each app to declare the view controllers it can present in other apps via a plist. Each service might be labeled with its role, like these:

    – Document picker
    – Sharing service
    – Upload service

  The specific set of roles might expand over time, but the fundamental advantage is the ability for an app share its functionality with other apps on the system.
   

• XPC and Sandboxing
  XPC is a framework for creating and managing helper processes, introduced in OS X 10.7. It and allows the developer to segment their app into multiple processes. There are two main advantages to this structure: stability and privilege separation.

  Stability is a simple one to understand: If one of the helper processes crashes, the main app is not affected; it can just carry on and launch the helper process again. If one portion of your app is especially prone to crashing (perhaps it parses user input?), you could separate that out into a separate process, and now your app is more stable.

  Privilege separation is the ability to limit the access of a process. If your parser has a vulnerability that allows access to any portion of memory, a malicious user might be able to gain access to data meant to be secure, such as user passwords, and upload them to a server². On OS X, XPC services can also be given a more restrictive sandbox, such that the helper process would not even have access to the network. Even if there’s a vulnerability in your parser code, blocking the ability of the parser to upload data to the network means that you’ve greatly limited the damage a malicious app can do.
   

• Third-party keyboards?
  Users have long requesting support for third-party keyboards in iOS. One of my friends says that the main reason she won’t get an iPhone is that she the Swype keyboard is not supported on iOS.

  Third-party keyboards have always been a security concern, though. A keyboard has access to every key you type. This means it has access to every username, password, social security number, and credit card number the user types in any app. Apple has long prioritized privacy and security over user features. I’ve always assumed that this was simply the death knell of third-party keyboard support in iOS.

  However, if we’ve already added App Services and Sandboxing in iOS 8, then there might be a way forward. There might be a special type of app service for third-party keyboards. These keyboard services would run in a very restricted sandbox; they would likely have no access to network, location, contacts, photos, etc. It could not launch other app services. Without this access, even a malicious keylogging keyboard would have no way to report your data. With these restrictions, Apple might consider allowing third-party keyboards.

  I think a lot of people would be excited to see this in iOS 8. It’s possible, though, that Apple might prove out app services in iOS 8 before adding keyboard support in a later release. I won’t say that I think this one’s going to happen at WWDC 2014—it probably won’t. But I’ll hope for it anyway.
   

• Healthbook
  Pretty much every rumor for months has indicated that iOS 8 will include a Healthbook app. It will apparently be able to track various health related biometrics, such as activity, sleep quality, heart rate, blood pressure, etc.

  It’s a cool idea. The main question is how the data will be collected. Some metrics (step count, etc.) can be inferred just by motion of the phone itself. The rumors indicate, though, that it will have far more data than that. A report from 9to5Mac indicates that it will track metrics like “heart rate, hydration, blood pressure, physical activity, nutrition, blood sugar, sleep, respiratory rate, oxygen saturation, and weight.” Some of these could perhaps be entered manually by the user, but if this is going to have any impact at all, most of this data collection has to be automatic.

  The rumored “iWatch” might be able to provide more of this data, as it would have direct skin contact. However, I think it’s unlikely that any wearable tech will be announced at WWDC. Without that, I’m not sure how useful a Healthbook feature would be. If iWatch is to be released this fall, then perhaps Apple will refrain from announcing it at WWDC, but include Healthbook in iOS 8 when it ships this fall.

  Color me skeptical that we’ll hear about Healthbook at iOS 8. I won’t rule it out, but I’m skeptical. I just don’t see how it can be useful without greater ecosystem support.
    

• Much improved javascript performance
  Javascript performance is slower in third-party apps than in the native Safari app because the JIT compilation techniques used in Safari require write access to executable memory pages. This is considered a security concern in third-party apps, and thus JIT has been disabled there. I would be very surprised if this performance restriction is not removed in iOS 8 by means of out-of-process execution or rendering.

  I’m calling this one. It’s coming.

There are a lot of TBA labs on the Tools track. I think there will be some really exciting stuff here. I keep a fairly close eye on the clang commit logs, though, and I’ve got a couple predictions.

• Better formatting
  The clang-format project is an automatic code formatting tool built on clang libraries. While Xcode’s code formatting ability is passable right now, they’re nothing spectacular. In particular, Xcode often does really dumb things with multi-line dictionary literals or array literals. I’m hoping we’ll see that improved in Xcode 5.2 (or whatever’s coming next.)
   
• Fewer tolls at our toll-free bridges
  ARC has done lots of wonderful things, but one thing it hasn’t done is simplified toll-free bridging. Instead, we often see (__bridge MyFoo*) casts to specifically indicate that we don’t want any memory management to happen. I think we’ll see many of those casts disappear in common cases.
   
• Better Beta Distribution tools
  Earlier this year, Apple acquired Burstly, the owners of TestFlight. TestFlight is a very widely-used service for distributing and managing beta versions of in-development apps. Shortly after the purchase, their Android platform was shut down. Beta distribution is a pain on both iOS and OS X right now. It involves collecting device UDIDs, managing provisioning profiles, etc. On Android, by contrast, users can be added to a beta simply by adding them to a Google Group. This is an area where developers are often frustrated with the Apple platform, and it’s a great opportunity for them to win back some developer goodwill. I’m hopeful we’ll see something exciting.
   
• More improvements around Modules
  Last year, Apple introduced modules as a compiler feature. They enable the @import keyword, enable auto-linking of frameworks, and can make compilation times much faster. However, so far it’s only been available for importing system frameworks. I’ve seen some commits on the Clang logs indicating that support for user modules is under development. I don’t know if it will be ready for WWDC or not, but I’d love to see what the new possibilities here are.
   
• Mogenerator (please?)
  Mogenerator is a great tool for working with Core Data. It automatically generates property declarations for you in .h and .m files, and then creates subclasses of those auto-generated classes for developer customization. If you’re not using it, you absolutely should be. Even some Apple teams use it internally.

  Frankly, it seems insane that something like this isn’t part of Xcode already.

Last year, I predicted that most of the iCloud talk at WWDC would be about how they’ve fixed all the bugs (especially with the iCloud-Core Data integration), and would not be announcing new features. Well, here’s a quote from last year’s Platforms State of the Union:

So this is an area that we have decided to not implement any new features this year but instead to focus on reliability and quality.

Nailed it. This year, I think we’ll be back in feature land. I really have no solid evidence on any of the following points; they’re just guesses and wishes, not predictions.

• Improved Photo Stream service
  It’s been said by many people: Instead of all the photos living on your device, with only the most recent ones living on Photo Stream, it should be the other way around. iCloud should store all my photos, and my phone should be able to download them on demand. Server storage is incredibly cheap these days; it seems like Apple should be able to do something better than what they’ve got right now.
   
• Larger quotas
  Speaking of server storage costs, I hope we see the free storage tier bumped up dramatically from the current 5GB. Device backups alone can take up the majority of the free 5GB tier; I’ve turned off iCloud Backup on one of my devices because I was running out of space. If “always backed up, all the time” is supposed to be one of the big features of iCloud Backup, then they need to offer more space.
   
• Server access
  One of the problems with iCloud document storage is that developers have no external access to the data. For example, many users have asked us at Day One for a way to add journal entries online. With iCloud document storage, there’s simply no way for us to do this. Third-party servers have no access to the user’s iCloud storage.

  If Apple allows server access, expect to see server provisioning profiles as part of it. People will complain about it, but I don’t see Apple allowing this any other way.

A few other predictions that just didn’t fit anywhere above:

1: Of course, not all of those sessions will contain earth-shattering revelations; pretty much any mention of the word “new” is enough to redact the entire session until after the keynote. And yet, somehow “What’s New in Foundation Networking” slips through unredacted. Not sure what’s up with that.↩

2: This is perhaps a lesser concern on iOS, simply due to the difficulty of getting malicious payloads into the target app and the inability to spawn separate processes. Nevertheless, it’s one that should not be simply ignored.↩

3: Yes, I’m totally taunting you here. The information is publicly available, and has been for weeks, but I haven’t seen anyone else discussing it. But I don’t want to be the one to spoil Christmas morning! The name of this class isn’t actually all that exciting, but I think the technology behind it will make a lot of people happy. ↩