Rumored MacBook Pro OLED touch bar to mimic iPad Pro?

Last week brought the first—and surprising—rumor from AppleInsider of an OLED touch bar above a new MacBook Pro (MBP) keyboard. At the time, I tweeted an image I mocked up of what that touch bar may represent.

This week brings a fresh rumor, including a supposed spy shot, of the OLED touch bar, so I thought I’d write a blog post to further explain my mockup from last week, with the amazing ways it could be used on a Mac.

Continue reading

Advertisements
Standard

10 Clues to the Future of Universal Apps and the Apple App Store

The other day I told you about how OS X may become a legacy operating system. That won’t happen overnight; it’ll take a few years. Today I’d like to discuss what might happen in the meantime. I’ll take a bunch of seemingly unrelated facts and see if I can form a realistic story out of them.

I’ve been thinking a lot about Apple’s App Stores lately, especially the Mac App Store which has had so much grumbling about it on Twitter and the blogosphere. In case you haven’t heard, the main complaints are: the Mac App Store doesn’t have as many features as the iOS App Store, apps seem to sit in the queue for longer periods before being approved, apps are sandboxed much like iOS apps, there’s no upgrade pricing for apps, there are no free trials available, and it’s hard to discover new apps based on a very primitive search mechanism.

When a piece of software, such as the Mac App Store appears to be abandoned by Apple, two things immediately spring to mind: either it really is being abandoned and Apple is quietly suggesting you move along without it, or Apple has a huge redesign in progress and doesn’t want to expend time & money on the old version but the new version isn’t ready yet. So they just stay quiet.

A subset of the second option (or, perhaps, a combination of the two options) is that the Mac App Store is going to be abandoned because OS X apps will become more like iOS apps, and there will be a grand unification of the app stores into one App Store.

It’s not too hard to conjure up a story for a unified App Store; here’s some evidence for that.

  1. Apple has been moving to 64-bit OSes and apps for several years. OS X apps have been 64-bit for several years and even iOS apps have been allowed to be 64-bit since the A7 CPU was announced in the iPhone 5S.
  2. Over a year ago, Apple required that iOS apps uploaded to the App Store be 64-bit (even if they also included a 32-bit version). Thus both iOS and OS X apps are 64-bit.
  3. As of Xcode 7, Apple has allowed iOS developers to specify that their apps work only on 64-bit devices. So even though iOS 9 runs on older 32-bit CPUs, iPhones and iPads that contain 32-bit CPUs would not be able to run certain performance-hungry 64-bit apps. App compatibility is no longer just based on iOS version.
  4. For the past couple years, the release notes for Xcode have mentioned that Apple has deprecated “garbage collected” apps on OS X. They’ve even given us a timeline: These older apps, which use a type of memory management that is not supported on iOS, will no longer work in OS X 10.12. This means Apple could make iOS and OS X even more alike next year at WWDC 2016, since both types of apps will use ARC, a more efficient technique that allows iOS devices to use less RAM than Windows 10 or Android apps. Thus both iOS and OS X apps use ARC memory management.
  5. Unlike Microsoft, which came out with the completely new Windows 8 and forced both desktop and mobile users and developers to adapt to a completely new interaction model and APIs, Apple has been gradually—but purposefully—making iOS and OS X more and more similar. They’ve been doing this to users by adding iOS features to OS X, adding OS X features to iOS, and adding new features to both simultaneously (such as Extensions). Likewise, for developers, Apple has been adding iOS APIs to OS X (such as table views, collection views, & tab views.), adding OS X APIs to iOS (TypeKit, JavaScript Core, etc.), and adding new APIs to both (CloudKit, HomeKit, etc.). Thus, year by year, iOS and OS X APIs become more and more similar.
  6. Apple already has “unified” apps for iOS and tvOS by allowing developers to specify that buying an app on iOS results in the same app being free on tvOS and vice versa. An educated guess would be that this is a half-step to a truly unified app, but some infrastructure wasn’t ready yet so Apple had to invent this temporary solution. So Apple is clearly looking at unification.
  7. There’s been a lot of developer angst about how different WatchKit is from standard iOS development (watchOS and tvOS are basically iOS with some libraries removed and new UI paradigms added). But remember that this first Apple Watch uses a 32-bit CPU. In fact the Apple Watch is the only device Apple still sells that’s 32-bit. Perhaps Apple is waiting to open up the APIs a little bit until the Watch CPU and WatchKit APIs are 64-bit.
  8. At WWDC 2015, Apple announced that one feature of App Thinning is BitCode, which allows developers to upload an intermediate form of their app, which Apple can later optimize for different CPUs. Yes, I know that Apple’s Chris Lattner has disavowed this possibility, so it’s not a key requirement of my theory, but then again he could be saying that because they don’t want to give away their plan. Remember how Apple was never going to have a stylus? Another possibility is that Apple will be coming out with a B-series of CPUs, but instead of being optimized for battery life like the A9 and A9X, they’re optimized for desktops and laptops. BitCode might make more sense in this scenario, allowing apps written for iOS to also work on AppleOS (see point #10, below).
  9. Also at WWDC 2015, Apple merged their iOS and OS X developer programs. If you create iOS apps you can now create OS X apps, and vice versa, at no additional cost. This would also be a key component of a unified App Store.
  10. Apple is presumably working on a laptop and/or convertible laptop/tablet that will feature an ARM CPU and run a derivative of iOS, much like tvOS and watchOS are derivatives of iOS. Perhaps it will be called iOS or perhaps AppleOS (iOS with an OS X-like UI, optimized for keyboards & mice) which might run on an AppleBook laptop. In any case, iOS will need to be modified to be more keyboard- and mouse-friendly. Apple is part way there already—iOS features keyboard shortcuts prominently on the iPad Pro with Smart Keyboard, and Apple has “focus” figured out for tvOS. “Focus” is the ability to move from one control to another (say, from a button to a text field) without using a touchscreen. On tvOS it’s done through swiping on the Siri Remote; on a laptop, it would be done by using the Tab key on a keyboard. Stephen Troughton-Smith has done some interesting investigative work showing how these features are already in iOS 9, they just haven’t been exposed publicly. He’s also show that tvOS has a built-in web browser, but it’s lacking a mouse cursor because Apple TV doesn’t have a mouse.

https://twitter.com/stroughtonsmith/status/664633260434157568

Now, it’s possible that I’m conjuring up theories out of thin air, but all these data points seem to make sense when you think that Apple is working on a unified App Store with unified apps that run on iOS, watchOS, tvOS, AppleOS(?), and OS X.

There would be a collection of APIs that, if developers stick to them, apps would run on all Apple devices and OSes. This API collection would comprise most or all of iOS as well as a large subset of OS X (the parts shared with iOS). Of course there will still be some platform- and device-specific abilities, since a Watch is not a TV.

Apps could use non-UI libraries that are shared across all devices, perhaps having different sets of storyboards to define the UI specifically for each type of device. (Even if you unify the APIs, it’s unreasonable to expect a Watch app to look or work the same as a TV app.)

Once the app was uploaded to the App Store, Apple could use the BitCode intermediate format to compile it for Ax ARM (iOS, tvOS, watchOS), Bx ARM (AppleOS, which otherwise would have no apps on Day One) and, possibly, Intel (OS X).

Developers and enterprises that create iOS or OS X apps have to start thinking about a unified system.

So what might the timeline be for this unified API, App Store, and ARM-based laptop- or desktop-like devices?

Apple is rumored to be releasing Apple Watch 2 in March 2016 or thereabouts. It would be unlikely that a unified API would debut at that announcement since too many other things would need to happen. But WWDC 2016 could see a big push with OS X 10.12 and iOS 10 becoming even more alike and more shared APIs and Xcode 8. Then, of course, autumn 2016 could see new hardware, perhaps an ARM (A10X or a new B1 CPU) convertible tablet/laptop hybrid, or even an ARM-based MacBook running iOS or AppleOS. And that would be a good time to debut a unified App Store for iOS, tvOS, AppleOS, and OS X.

Certainly, I’ve gotten some details wrong and over-interpreted a few data points. But I think it’s clear that something big is coming, whether it’s actually a unified API and App Stores, or just steps along the way.

(As I’m writing this, Apple announced that Phil Schiller will now be in charge of the App Store, along with most other developer functions.)

I believe it’s a mistake to continue thinking that OS X will live on forever as its own separate OS and App Store. Apple is too incentivized to make things easier for itself and third party apps by unifying CPU architectures, APIs, OSes, and App Stores. How exactly it’s going to work and what the timelines are is open to speculation.

Developers and enterprises that create iOS or OS X apps have to start thinking about a unified system.

Don’t think iOS apps never have to worry about non-touch screens or laptops or desktops. Don’t think OS X apps can be kept out of the App Store forever, or that they won’t be required to be sandboxed, or that OS X apps will be priced differently from iOS apps.

These will be challenging times for developers, businesses, and business models. It’s a very different world from even 10 years ago. Look to the future and embrace change. It’s coming.

Standard

The Apple Watch is the New iPhone—and the iPhone is the New iPad

Apple had a plan when they introduced the iPhone. The iPhone was going to be your new pocket computer—easily at hand all the time. No bigger than a handful (and at the time, even a 3.5” screen was considered huge for a phone). It probably would’ve gotten thinner and thinner, until it became like the iPod touch 5th generation. (Have you held one of those recently? Pretty amazing.) iPhone app developers were given tools to carefully craft apps at a fixed screen size.

It’s been said that the iPad was in development even before the iPhone, but the phone was going to be the generate more money because everyone had a phone. So the tablet form factor (the iPad) was going to be an accessory. After being wowed by an iPhone, users would eventually want something that wasn’t so pocketable, but still booted up instantly, was thin & light & touchable, very secure, and ran the same apps as their phone.

That was the plan.

But a funny thing happened along the way:  Continue reading

Standard

Apple software quality: is the sky really falling?

There’s been a lot of hand-wringing for the past few months about the perceived quality of Apple’s software, and it seems to have reached fever pitch with yesterday’s post by Marco Arment (http://www.marco.org/2015/01/04/apple-lost-functional-high-ground).

Rather than whine about any perceived “losing” on Apple’s part, let me describe what I think is happening, what’s driving those changes, and how long those drivers might compel change into the future.

What’s happening?

The claim is that Apple’s <insert software name here> is buggy and/or getting buggier. <Insert software here> can refer to any or all of iOS 7, iOS 8, OS X 10.9, OS X 10.10, Xcode, Swift, iPhoto, etc.

I agree with most of the Apple-software-quality-is-declining blog posts in terms of individual problems they’ve pointed out. Yes, the iOS 8.0.1 bug fix went terribly wrong. Yes, there are problems with rotation handling in iOS 8. Yes, Xcode’s code formatter crashes constantly when writing Swift code (although this seems to have been mostly fixed recently). Yes, OS X 10.10 had wifi problems.

In Apple’s defense, consider the fact that the iOS 8.0.1 problem was detected within hours, and fixed in a day or two. It was also due to a configuration issue that wasn’t tested on live phone networks. Also in Apple’s defense, consider that none of these software quality problems resulted in lost data. Anyone around for OS X’s early days remembers the 10.3 Oxford chip set problem with Firewire 800 devices, and how that *did* result in lost data. http://www.cnet.com/news/firewire-800-drives-with-oxford-922-apple-statement-lacie-wiebetech-owc-updates-oxford-statement-taking-precautions/

Now this doesn’t mean I think Apple deserves a Get Out of Jail Free card. I mean, when you ship a laptop with no physical network jack and then you ship an OS update that messes up wifi, well, your customers deserve to be angry at their loss of productivity.

So, sure, Apple has botched a few things, but I think it’s pretty obvious that they’ve botched things at least as bad in the past. So let’s not bring up the “this wouldn’t happen if Steve Jobs were around” mantra, OK? Great.

What’s driving these quality problems?

Are there more problems than in the past? Yes, but that’s because of the enormous amount of change lately.

  • iOS and OS X are much more complicated than they used to be, and there are a lot more users worldwide.
  • Apple is trying to make iOS and OS X more alike than they already are (for users and developers), as ARM-based, touch-driven devices catch up to the speed and screen size of Intel-based, keyboard-driven devices.
  • Apple is innovating on the developer front (Xcode 6, Swift, Adaptive UI, Apple Pay, Health Kit, Home Kit, Extensions, Metal, iCloud, etc.).
  • Apple is innovating on the device front (Apple TV, CarPlay, Apple Watch, iPhone 6/6 Plus, A8 and A8X chips, etc.)

Despite the fact that Apple is famous for having a limited number of hardware devices for sale, this is an enormous amount of change. I can’t emphasize this enough. For the past two years, Wall Street has been saying Apple wasn’t innovating—yet this year Apple revealed enormous changes in APIs and devices that it has been working on in secret for 2 or more years.

So what’s driving these software quality problems? In a word, change. Enormous change, at a rapid pace.

Why is there this enormous ecosystem change?

OK, so enormous, rapid change means that software is harder to get right, out the door. But why? Why is Apple creating enormous change so rapidly?

The answer to that is complicated. It’s a lot of things: competition for users, competition for developers, and changes within Apple.

It’s not just Apple vs. Microsoft anymore. Apple is competing for users with Microsoft, Google, Amazon, and Facebook. The biggest challenges are Google—with Android, Chrome, search, and services—and Facebook, with the largest social network in the world. Court rulings have demonstrated that it’s hard for Apple to protect the difficult, multi-year work involved in device and UX design with intellectual property rights (patents). Apple has to compete a different way, so it’s going to be constant innovation.

Apple’s also competing for developers. Google has lots of developer APIs for its services, Facebook has Parse, and of course Microsoft has myriad popular developer tools both for Windows and the cloud.

The third area that has driven so much change is the shuffling of Apple’s management. Not only has Steve Jobs passed away, but also Tim Cook fired Scott Forstall. While neither of these events is cause for alarm, both Jobs and Forstall had strong opinions about user experience that conflicted with Jony Ives and possibly others at Apple. That resulted in the quick jettisoning of the ostensibly dated look of iOS 6 and OS X 10.9—and its skeuomorphic baggage—and the new streamlined look, motion effects, and transparency effects of iOS 7 and OS X 10.10. That executive shuffling may also have resulted in the new larger iPhones, requiring lots of rethinking of developer tools for layout out apps.

So what does the future hold?

OK, we have enormous change, driven by internal and external forces (management changes and competition). Can we expect this to continue? Are Apple users doomed to eternal software glitches?

Well, I think it’ll continue for the next 6 months at a minimum. We still have the iPad 6 Pro/Plus coming, which may require more UX and API changes. We have the Apple Watch, for which Apple has released a preliminary SDK, but promises even more changes in a year or so. Apple TV is set for a refresh. CarPlay is in its infancy. And now Mattt Thompson is thinking Swift may be only the beginning of a much bigger change for developer tools and APIs (The Death of Cocoa: http://nshipster.com/the-death-of-cocoa/).

So hold on tight, folks. The next year may involve almost as many changes as the past year. And there may be more glitches along the way.

My feeling is that this is unavoidable, with the enormous change that is happening at Apple.

The good news, though, is that I don’t think this rapid rate of change is sustainable. And I don’t mean just users and developers. I think Apple has some very sharp people, but even they cannot sustain this rapid change of pace forever.

The rapid pace of change will ebb and flow. Remember, Apple doesn’t come out with amazing new category-killer devices every year. There are 5-10 years between new categories: Mac, iPod, iPhone, iPad, and now Apple Watch.

So this torrid pace will continue for a year, and then I think it will calm down. And then Apple’s software developers can catch up. And 3rd party developers can catch up. And users will be able to breath a sigh a relief. But not before this tumultuous 2-year period (we’re half way through it now) is over.

Standard

Why the iPhone 6’s will be Probably be This Screen Size

In my previous post (2 Reasons Why the iPhone 6 Won’t Need to be 1.5x Retina Resolution), I explained why Apple isn’t so constrained about the rumored iPhone 6 screen sizes. That blog post was long enough, so I thought I’d break out into a new post exactly what size(s) I’m expecting in the iPhone 6 4.7″ and 5.5″ phones (assuming the rumors are real).

I’m thinking Apple will make both phones at 1920×1080. Then they will be able to contain letter-boxed 1.5x-sized existing apps (fitting inside a 1704×960 rectangle). Each phone will have 1.5x-sized tap targets (66 points tall instead of 44 points tall) but will still have an extra 10% or so extra space vertically (1920 vs 1704) and horizontally (1080 vs 960), so there’s a little more room for app content.

The benefit to users: Continue reading

Standard