Apple

Thoughts on Apple's 2015 Macbook

While Apple Watch was the headline product of yesterday's keynote, the new Macbook is by far the most interesting news.

It's been many years since we had a proper 'MacBook'. The white plastic MacBook was discontinued in July 2011 and since then, Apple's line has consisted of the MacBook Pro and MacBook Air. The MacBook was always positioned as the entry level portable Mac and it's important to remember when looking at the 2015 Macbook.

Many expected the new MacBook to replace the MacBook Air. It shares many characteristics as the current Airs as well as a few great updates including a retina display, thinner body, and a better trackpad and keyboard. But the MacBook Air line has continued to live on albeit with faster processors.

Here in lies the difference. The Air is now positioned between the MacBook and the MacBook Pro. The Air offers upgrades like adding more RAM, faster CPU, and more storage. The new MacBook comes in 2 basic models with limited upgrades available. It's the iPad of the Mac world. In fact, it's positioned so much like an iPad that it comes in 2 colors and 2 configurations.

The addition of the new MacBook makes the MacBook Air line look antiquated and bulky. The Air is for people who want a faster processor than the basic M-class included in the MacBook as well as more than 8GB RAM or a larger display than 12 inch. The MacBook Air is also the only Apple product remaining that ships without a retina display. It's low-hanging fruit and I'll bet 2015 will be the year Apple completes the Retina transition.

The new MacBook is positioned as the future of Apple portables. The 13-inch MacBook Pro received the tactic trackpad upgrade and faster CPUs but the 15-inch curiously didn't. Apple has purposely left room for a future announcement with a new generation of MacBook Airs and larger MacBook Pros. Your guess is as good as mine but I think these future devices are dependant on new software features in OS X 10.11 or 10.10.4.

And then there's USB-C port. The new MacBook includes the new connector which promises to replace USB 3, Display, and HDMI. In fact, there are no other ports on the device which has allowed it to be so thin. In fact, the M-class chipset in this MacBook doesn't support Thunderbolt. This isn't a sign of Apple killing Thunderbolt, it strictly isn't supported by Intel.

The new MacBook isn't for people who are plugging in storage devices or external displays. The new MacBook is for users who love iPad but want a traditional desktop. It's perfect for writers and casual Safari browsing. This isn't a machine you'll be running Xcode on all day. This is for your mom, a student, a blogger.

The MacBook Air isn't going anywhere; the next generation will blow the MacBook away.

App Store Metadata Rejection

Screenshot++, my new screenshot management app for iOS, was submitted more than a week ago to App Store Review and they returned this week to say the App Preview video was rejected.

Specifically, Apple took issue with showing screenshots being taken in apps other than mine. The offending apps weren't apps from the App Store, they were Calendar and Maps - both built into every iOS device. I (wrongfully) assumed this would be acceptable.

It appears they're strictly adhering to the rule that App Preview footage is limited to video taken within your app and your app alone.

So how do I demonstrate to a potential customer the process of taking a screenshot? I'll have to stick with in-app instruction and text in the App Store page screenshots. It's unfortunate that I'll have to stick with in-app instruction and App Store page text. Potential customers may or may not take the time to read text on my App Store page but everyone who watches the Preview video will understand the concept from example.

This may seem trivial but I have seconds to demonstrate the app's value proposition. I cannot assume that every iOS device owner knows how to take a screenshot or even knows what a screenshot is. However, the majority of iOS users have screenshots littered through their Photo Library. For this reason, Screenshot++s App Store page isn't just selling the app, it's also for educating potential customers on why they need it. 

I broke one of the rules and had my app metadata rejected. (I believed this would be accepted. I want to avoid a metadata rejection at all costs, but here I am.) To be clear, it seems the app itself passed review but the Preview video did not. 

I swiftly removed the offending video and resubmitted. I'll now have to wait another week to go through the queue and have everything reviewed for the second time.

This is my biggest problem with the App Review system. Inefficiencies waste valuable time for both the developer and Apple. I'll explain:

The original review of Screenshot++ included the app itself, Preview video, screenshots, keywords, and app description. If everything but the preview videos was approved, why should everything have to be reviewed again if it hadn't changed?

A better approach, after sending the rejection email would be to provide the developer with a selection of next steps. Either I resubmit the app (the current and only option) or Apple provides the option to make a quick metadata change if completed within a short amount of time.

Consider a better system: I receive the metadata rejection that the Preview video cannot be approved. I then log into iTunes Connect, remove the video and press 'Update' (or something equivalent). The app then goes back to the review employee who sees the change and continues with the app approval.

The above scenario eliminates the second review, saving at minimum an hour of a review employees time, and my app is available for purchase on the App Store a full week before the current system allows.

Apple's 'Early, Mid, Late'

At last year's iPhone event, Apple unveiled the Apple Watch and said it would be available for consumers in 'Early 2015'. What exactly does that mean?

Most, including myself, assumed this meant anytime between January 1 and June 30 2015 - that's a broad timeframe.

During this week's 2015 Q1 earning's call, Tim Cook provided some clarity -

Cook says Early 2015 means first four months, Mid means next four months, Late means last four months…
— 9to5Mac, http://9to5mac.com/2015/01/27/fy15-q1-earnings-call/

While this may not seem newsworthy, it's important to note that Apple has historically been loose-goosy with their promised release timeframes. You can bet that if something is promised in 'May', it will be released after the 15th.

Apple has burned itself in the past when it couldn't deliver on a promised launch date. For me, a 6 month window lands far on the obscure side of the fence. It's nice to see Tim providing some clarity on Apple's wording when it comes to timeframes.

Functional High Ground Retort

I fear that Apple’s leadership doesn’t realize quite how badly and deeply their software flaws have damaged their reputation, because if they realized it, they’d make serious changes that don’t appear to be happening. Instead, the opposite appears to be happening: the pace of rapid updates on multiple product lines seems to be expanding and accelerating.
— Marco Arment, marco.org

Much has been written about Marco Arment's piece from Monday night, some constructive, most sensationalist drivel. The fundamental assumption here is that Apple's recent software riddled with bugs and was shipped before it was ready. I disagree.

I used OS X from Jaguar to Yosemite, iOS 1.0 through 8.1, and every release in between. Are there more bugs in today's software than 2007 or 2004?

Apple's software, like any piece of software, has always had bugs. iOS 7.0 at launch was unstable at the best of times and it took Apple months to release iOS 7.1 that addressed many of those issues. iOS 8.0 was much closer to fully baked than its predecessor on launch. Apples to Oranges, perhaps, but I see it as an improvement.

Going back to the Mac, I've yet to encounter most of the Yosemite bugs. In fact, Yosemite fixed many of the bugs I ran into with Mavericks. Both releases have their issues but is 10.10 worse than 10.9? Not in my experience.

If we're going to compare OS releases, let's level the playing field.

The debate shouldn't be whether Yosemite is less stable than Snow Leopard. The debate is whether 10.10.1 is less stable than 10.6.1. You can't compare the newly released Yosemite against Snow Leopard after it received 8 maintenance releases. If you want to avoid the early bugs, most should wait for 10.x.1 before you upgrade your Mac. I'd even suggest 10.x.2 for the conservative user.

Looking back on OS X releases ending in .1, I'd wager that Yosemite is the most stable since Snow Leopard. It's the first time in years that Finder isn't crashing for me at least once a week and I've yet to kernel panic on an iMac I use for work every day.

I simply don't accept that Apple's software is worse than it has been. It's easy to look back at the days of yore with fond memories and forget the bugs that existed in Panther and Leopard. After all, you're (probibly) not using 10 year old Macs today or fighting against its bugs.

Apple changed development schedules for iOS and OS X so they would have concurrent release dates. Among the many pro reasons, this allowed them to release features on both platforms concurrently, resulting in a win for end users and developers.

Is Apple's leadership aware of Marco's post and the growing complaints about Apple's software reliability? Yes.

Are they willing to stay quiet and ride out the storm? Time will tell.

Ambiguous App Store Guidelines

Panic's Transmit 1.1.1 is the latest app to fall victim to Apple's ambiguous App Store Guidelines. We have an exceptional app, made by talented and bright individuals, receiving a rejection because it violated a vague clause in the App Store Guidelines.

PCalc, another great calculator app, was recently rejected for adding calculation functionality into their iOS Today Widget even though Apple's Calculator app for OS X includes the same functionality.

Transmit, according to the App Store Review Team, was in violation because it sent data to other services that wasn't created in the app itself. Bah-humbug.

Transmit and PCalc aren't alone in trying to McGiver the increasingly vague guidelines, these are simply recent entries in a long list.

Apple seemed to be embracing developers at this year's WWDC, it seemed as though they were on our side. Looks like we jumped the gun. They have their own interests, of course, but it seemed we were in a new age of transparency.

iOS developers are now increasingly apprehensive to push the envelope on what's possible and that can only result in a poorer user experience.

Final note: as we steadily march forward to feature parity between iOS and OS X, why hinder the iOS platform? What division within Apple is reigning developers back?

The infighting within Apple is becoming clear and users and developers are taking the brunt end.

Creating iSource 2.5 for iOS 8

Tonight I finished work on the latest version of iSource APA (2.5). It supports and now requires iOS 8 and is currently awaiting review.

iOS 8 brings great new features and fixes many bugs introduced with iOS 7's interface redesign. Along with iOS 8 is Swift and Xcode 6.

The biggest features that users will notice first are Today and Sharing widgets. Shortly after WWDC14, I decided not to include support for these in apps that didn't absolutely need them. In the case of iSource, what was I going to include in a Today widget? A fancy slogan? An inspirational quote? Nope. I didn't want to take up people's time with a Today widget unless it provided real value.

Take the Clear Today widget. If you remove all the content in the app, it decides to give you a *cough* inspirational quote. I didn't ask for it but there it is. 

You also may notice a beta version of the Today widget I'm including in Bug Trackr 2.0. It tells you what you need to know while using the minimum amount of screen real estate possible.

Below, you'll see Pedometer++'s Today widget. Short and to the point, I like it.

iOS 8's Today view is still very much a UI playground and I realize developers are often scratching their heads about what to include there. Sometimes, the best thing to do is do nothing at all. 

Sharing widgets are another story all together. I would love to be able to create a resource share sheet, basically the same text entry you see in the app, but available through other apps. There would be a relatively low amount of apps you would want access to iSource's Share widget in but it could still be useful.

The problem is iOS 8's sharing data flow paradigm. The way iOS 8 works is that you select the data you want to share, tap the share button, and select the place or service you want to share to. An iSource share sheet would make sense in a scenario where the user, from anywhere in iOS, wants to add an entry, they bring up the iSource Share Sheet and enter in the resources parameters. But that reverses Apple's data flow in iOS 8's share sheets. It would be confusing to the user even if Apple approved it in App Review.

So for now, we're going to stay away from Today and Sharing widgets.


Also new in iSource 2.5 are completely redesigned resource icons. They fit in a whole lot better with the iOS ⅞ aesthetic and they're included as @1x/@2x/@3x (and @4x for then that day arrives) assets. The icon redesigns were something I had started last year when I added more assets but, since the introduction of @3x assets (which I didn't have), I decided to start from scratch on a new set.

With this version and unrelated to iOS 8 I decided to reintroduce landscape support for iPhone. This was only because of the new display sizes in the iPhone 6 and iPhone 6 plus. In the 1.0 version of iSource, I enabled landscape support because text entry was done directly in the table view. When I added the Entry Sheet around iSource 2.0, I removed landscape because springs and struts in Interface Builder didn't allow me to configure the sheet view as I wanted when displayed in landscape with the keyboard visible. With the addition of Size Classes in Xcode 6, its now possible for me to create different configurations of the entry sheet based on its size class.

Top right you'll see the traditional version of the Entry Sheet in iSource 2.5, complete with blurred background. Bottom right is the Entry Sheet in it's new landscape configuration. Nice eh? Thanks Size Classes!


At WWDC14, I was highly interested in playing around with iOS 8's new Embedded Framework support. iSource 2.5 includes the new iSourceKit framework and it's where I've put a lot of code and resources that I share between iSource APA and MLA. Without going into too much boring nitty gritty about maintaining two versions of the same app, frameworks are a godsend. For code within iSourceKit, I've been able to cut debug time in half and every minute saved debugging is one I can now spend on making great feature. Thank you Embedded Frameworks engineers at Apple!