Raw Thoughts on Apple's Spring Forward Event

Here are my (mainly) unprocessed notes of Apple’s Spring Forward event:

Apple TV

• HBO is probably a big deal.
• I expected new Apple TV hardware (and an SDK), but I think this was not the event nor the time to announce it, with all developers targetting the Apple Watch. Maybe WWDC 2015 can get us the long awaited SDK.
• Dropping the price given that they keep selling old hardware seems like a good move, and I would guess if a new OS with an SDK is comming implies that it will be supported.

ResearchKit

• The idea sounds great. I think using mobile devices for larger field samples makes sense, even if the sample is skewed in some ways.
• I like that it’s Open Source. It shows they are doing it for a greater good rather than to sell more devices. But…
  • In the past, Apple has promised to standarize FaceTime and didn’t.
  • I dont’t think Apple has been a good steward of Open Source projects in the past. What I would love to see, is Apple commiting to develop ResearchKit in the open¹. Open Source projects can’t be really open if they are only released alongside new OS versions and don’t have a somewhat public roadmap.

MacBook

• I’m glad it is still Intel and not ARM. I still need to boot into Windows from time to time, and I think that’s been one of the biggest benefits of the Intel transition.
• I’m not sure I like them using a single USB-C port, but I understand the rationale: this is a MacBook designed with iPad ideas, and this makes sense in this context.
• Using USB-C (an industry standard) is a great move. It will help move the adoption, as the original iMac did with USB, and lead to cheaper accessories in the near future. By the time all Macs have USB-C connectors, I guess will have a fair share of inexpensive hubs available.
• Additional thought: what prevents Apple to move iOS devices to USB-C now? The connector looks small enough, and it’s standard. You could charge your iPhone with the same cable that came to charge your MacBook.
• The new trackpad looks amazing. I’m courious how the Force Feedback settings work and feel.

16/64/128

Ever since announced, iOS devices stuck to a simple formula for storage sizes. You get the base model (8GB, 16GB depending when), and for USD 100 you can upgrade to the next storage tier. Storage tiers had been (up to 2014) twice the size each time, for example 16/32/64. Even if this was not logical to some¹ it was somehow easy to understand: storage bumps were linear in their multiplier (2x, 2x).

This year, this changed for the worse. Apple is now offering all their new devices (iPhone 6, 6 Plus, iPad Air 2, iPad mini 3) with storage tiers of 16/64/128. When I first say this during the original iPhone 6 / 6 Plus introduction, I wrote:

I like that the middle tier is now 64GB, but dislike that the bottom one remained at 16GB. It strikes me as unfair, although I understand the reasoning to try to drive customers to a more expensive device.

I was able to now pinpoint why I dislike this. The following screenshot is taken from Apple Store, when you choose an iPad mini 2 and can see the offered data plans:

Each carrier has a different pricing structure, but the intent is clear: drag you away from the cheapest plan. AT&T is the more obvious one: the jump from 250MB to 3GB is huge. Sprint is similar (although it’s first plan is way better than AT&T’s): the first jump gives you 3x the data, while the second only doubles it.

My feel with iOS storage bumps is that Apple is applying a similar strategy to try to drive you to the second tier. It’s not unfair, as I qualified it. But it’s something I expect from cellular carriers, not from Apple.

An idea: CloudKit for Family Sharing

CloudKit is the new syncing backend provided by Apple. Based on initial reviews and opinions, it appears to be great. I think, however, that there’s a low hanging fruit for Apple to take advantage of: CloudKit for Family Sharing.

As it works now, CloudKit provides two kinds of storages: Public and Private. Public storage is a huge DB shared among all the users of your app. It appears to be tuned or thought for apps like Instagram, where there’s a social graph and a large timeline.

The Private database is different: it works as part of each users iCloud storage and is limited in size by it. This appears to be tuned to syncing across devices. It has great use cases, and several apps could benefit from it ([Vesper]¹ and Things come to mind).

Both options leave a slice of the sync market unattended: sharing private data with other users. Think of apps like Notabli, or our own Shopster, where the most requested feature is by far syncing with other members of your household.

Do you see a pattern yet? There’s a big chance that several of the common sharing cases are among people in the same iCloud Family Sharing setup. Which brings me to the original idea: it would be great to have a third² CloudKit database for Family Sharing. This one would be similar to the Private database and count against the organizer space quota, and ideally a new API would allow you to easily move data from your private cloud to the family shared one.

This third option could go a long way to address a common sync need that is currently unsolved by what Apple offers³.

I’ve filed a bug report for this. If you think it may benefit you as well, feel free to use it as a reference.

UITableViewRowAction Introduction

iOS 7 saw the introduction of a new style for the swipe to delete in table view cells. The entire cell content was placed in a UIScrollView, and swiping would reveal the red Delete button. iOS Mail (and only that app) also sported an additional More menu item. This API, however was private.

In iOS 8, Apple finally made this API public ¹ for all of us to use, in the form of edit actions and UITableViewRowAction.

Usage

In order to provide your UITableViewCells with actions, you need to implement the method func tableView(tableView: UITableView, editActionsForRowAtIndexPath indexPath: NSIndexPath) -> [AnyObject]? of UITableViewDelegate.

The method retuns an array of actions. The order is of course important: the first item in the Array will be the rightmost (or leftmost on RTL user interfaces) item when you swipe the cell.

A sample implementation follows:

    override func tableView(tableView: UITableView, editActionsForRowAtIndexPath indexPath: NSIndexPath) -> [AnyObject]? {

        let deleteClosure = { (action: UITableViewRowAction!, indexPath: NSIndexPath!) -> Void in
            println("Delete closure called")
        }
        
        let moreClosure = { (action: UITableViewRowAction!, indexPath: NSIndexPath!) -> Void in
            println("More closure called")
        }
        
        let deleteAction = UITableViewRowAction(style: .Default, title: "Delete", handler: deleteClosure)
        let moreAction = UITableViewRowAction(style: .Normal, title: "More", handler: moreClosure)
        
        return [deleteAction, moreAction]
    }
    
    override func tableView(tableView: UITableView, commitEditingStyle editingStyle: UITableViewCellEditingStyle, forRowAtIndexPath indexPath: NSIndexPath) {
        
        // Intentionally blank. Required to use UITableViewRowActions
    }

This is how it looks when you swipe:

As you can see you need to return an array of UITableViewRowAction objects. UITableViewRowAction.init receives three parameters:

• style: either .Normal or .Default. .Normal doesn’t have a color, similar to the More button in iOS 7 Mail, and .Default is the standard destructive action, with the red background color.
• title: the label that will be shown to the user when swiping the row.
• handler: a closure (or block) with the handler that will be called when the action is selected by the user. The handler receives two parameters: the action itself, and the indexPath. Sadly, the handler doesn’t give you the UITableView as a parameter, so your handler needs to get a reference to that by other means.

As you may have noticed it in the sample code above: in addition to tableView:editActionsForRowAtIndexPath: you need to override tableView:commitEditingStyle:forRowAtIndexPath:, even though you can leave it blank. If the method is not present, the actions won’t show up on swipe².

In case you find it useful, you can download an interactive playground with this sample code.

Apple Watch Event Thoughts

After a little more than a day, and digesting the latest Apple event, I figured I’ll write my first thoughts.

I haven’t yet checked the latest iOS Simulators, nor rewatched the event video. I’m writing this as bullet points, as I don’t have any coherent thought to run through all of them.

Overall it was an amazing event (even with the poor streaming), except for the U2 part at the end, which fealt overacted and uncomfortable.

Apple Watch

Ever since I got my first mobile phone I stopped wearing a watch. I do have a Fitbit One, that I like and use everyday.

• It’s the first version. It the Watch success (and I think it will) it will be remembered fondly as the original iPod, iPhone or iPad.
• It’s a sad fact that it needs to be recharged overnight (even more, it appears to be designed with that use case in mind). Fitness trackers are used to track sleep, and one of the features I like the most is their silent alarms, so you can wake up in the morning without waking up the rest of the family. I figure we’ll get there eventually with the Apple Watch.
• I like how they made so many different bands and styles. I always considered a watch to be more about personal style than a phone, and I like how this is being addressed.
• The watch creates a new entry point for a potential halo effect on the iPhone. Some people might get attracted to the watch more than to the iPhone, creating new potential customers for both.
• We can always use more sensors. A gyro would be useful to measure stuff on a tennis or golf player for example. If the iPhone is any experience, sensors will be added.
• I’m really curious on the update cycle for the watch. With no subsidy and potentially high prices, what’s the expectation on users updating their watches? How will that fragment the app ecosystem?
• I’d love it to be thinner. Once again, I can see this happening sooner rather than later, as it did with the iPad 2.
• I know about Option + Shift + K. Did you know about Simbol to type it on the iOS?

iPhone 6 and 6 Plus

• They look big and great. If I were to pick one, I think I’d go with iPhone 6. The huge hardware change will certainly draw a lot of people to the iPhone, either switching from Android for the first time, or coming back after feeling dissapointed by smaller screens.
• I like that the middle tier is now 64GB, but dislike that the bottom one remained at 16GB. It strikes me as unfair¹, although I understand the reasoning to try to drive customers to a more expensive device.
• 3x assets and the scaling is weird. I figure it’s a stop gap measure until we can get screens at 4x resolutions, so we can go back to pixel perfect assets if we wish to. While iOS 7 and 8 have a visual style that do not require pixel perfect mockups, iOS 7 was touted as designed for retina displays, and the recommendation was to use retina assets (like 1px lines) which might not look good on the 6 Plus.
• It’s a sad reality, but the leaks during the buildup for these events keep being real. At this point, Apple can only either preannounce hard, as they did with the Apple Watch, or surprise us with software, as with iOS 7, Yosemite or Swift. It’s a bittersweet feeling: I like the huge reveals, but as a developer, I can also see the great value in revealing software that has the potential of changing the hardware we already own.

Apple Pay

• I really love the focus on privacy. The fact that the credit card information remains on the phone is reassuring.
• There are two steps that are moody for me:
  • How is the validation with the bank done? Will Apple have to partner with every bank that provides credit cards?
  • If credit cards are local to the phone, what happens when they add the card you have on file on your Apple ID? Is it transfered? Referenced?
• Living in Argentina, I don’t see this coming soon here, but I’m certainly used to that.