Here’s what I’ve been thinking about the next Apple TV.
Operating System and App Store
I think the Apple TV will run (as it has since the black hardware we currently have) a version of iOS. I’m guessing we’ll get a formal name for it: tvOS1.
tvOS will be the same familiar set of frameworks for iOS with some new top level UI elements (think the equivalent of UIKit) and support for a different interaction model (remote control clicks and selections instead of tapping, or swiping on a pad).
There’s no doubt in my mind that tvOS will support an App Store. I’m looking forward to apps like Plex to be natively available, as well as apps for TV channels and sports. The current channels on the Apple TV are limited in both functionality and features, while having a full blown App Store will allow developers to create better experiences for the TV.
If my guess is correct, all the existing apps will be easy to port, so we’ll have a large number of apps in weeks.
The Multiuser challenge
Let’s think of some scenarios:
If you have a tvOS running Apple TV with an App Store, it will make sense to have it support Handoff. Say you start watching a YouTube video on your iPhone, as soon as you enter your living room and turn the TV on, you can hand it off to the YouTube app running there, and you can leave your phone.
Say you use Spotlight on tvOS to search for a TV show. It will display results from the Netflix app, but Netflix supports different user profiles, some even filtering kids only content.
The main challenge I see here is that while iPhones are strictly personal devices, the Apple TV is a shared resource in a shared space at home. I don’t have an answer to this, but I’d love for tvOS to ship with an implementation of multi-user support. All iOS apps are already multi-user ready (whenever you get a folder from the OS, you use the same API as OS X that returns the current users folder), so this is doable.2
iOS is an amazing platform for gaming. Not only for indie games, but for AAA games as well. With a powerful hardware and Game Controller support the possibilities are huge.
I think the Apple TV has the potential of becoming a huge Game Console for casual (or why not all) gamers.
Given the time they got on stage, my guess is that Apple think of them as a big deal. HealthKit got its device with the Apple Watch. I think HomeKit is about to get its with the Apple TV.
As our homes become full of connected devices, having a central hub that is part of our home LAN and can be always on will be essential for controlling the devices while away.
I won’t speculate on the hardware, but from what 9to5mac published it appears that will get a fairly modern A-series CPU and a new remote.
I do have a few comments, though:
The CPU and GPU don’t need to be as speed-limited as in mobile devices. Even without a fan, I’m confident they can run it at higher clock speeds, or don’t have them throttle that fast.
Having IR on the remote doesn’t make much sense to me, unless Apple wants to make its remote a universal remote, which I don’t think. Universal Remotes are a mess3, and how well they work depends on the other components manufacturers4, which is something Apple doesn’t like.
The buildup for this Apple TV revision has been large. We can easily see traces of it in frameworks that originally shipped with iOS 8. I’m eager to see both new hardware and how Apple solves the challenges in the OS side.
And if we don’t get it, at least I’ll get to use it for the rest of this post. ↩
And if we get this feature, Apple will be running out of reasonable excuses to not include multi-user support on the iPad. ↩
Today we released CocoaPods thumbs. It’s a CocoaPods plugin that allows users to check for peer votes of the dependencies
they are including in the project. We are using it at Quadion (our thumbs are public, you can check them here).
We started using CocoaPods as soon as we discovered. It’s great for seasoned developers, but can quickly turn into a double-edged sword. Searching for the magical Podspec that solves a specific problem quickly becomes second nature to any developer (only second to copying and pasting unknown code from Stack Overflow).
The problem is that there are tons of Podspecs, and the quality varies hugely. From long time abandoned code, to code that violates AppStore submission rules by using private APIs, to code with too many bugs.
So I wanted to improve on this, at least a little bit, and then CocoaPods thumbs was born.
How it works
The use case is straigforward. There’s a server that returns a JSON with a given format, including Podspecs (with version requirements) and votes (optionally with comments).
Users first register the server URL (which conveniently can be a GitHub URL to the RAW JSON file), and then simply run pod thumbs from a folder with a Podfile. When run, CocoaPods thumbs will:
Calculate the dependencies.
Check the server votes.
Match the resolved dependencies with the votes, and display it to the users.
There’s also an alternative command to just display the votes of a single Podspec, useful to help you decide if a particular dependency has opinions among your team members.
I’m not sure how this will evolve. I’d love for this to become a part of CocoaPods daily usage for more people, and maybe consolidate our thumb lists instead of each team having their own. For now, if you use it, feel free to submig Pull Requests, or suggest enhancements on GitHub.
Installing Jenkins is usually easy. It’s even easier on the Mac using Homebrew. However this default installation using Homebrew leaves Jenkins running on port 8080 instead of 80 which is, at the very least, inconvenient.
Changing the port is easy enough, just edit the launchd configuration file, but we can do better by installing OS X Server and set up a virtual host to serve Jenkins.
Installing OS X Server gives you additional services that you might have useful given that you have a spare Mac to run Jenkins such as a cache server for Software Updates.
Installing OS X Server
OS X Server is available on the Mac App Store. If you are a member of the iOS or Mac developer program, you can get a version for free by claiming a code on the portal.
Installing Jenkins on OS X
There are several ways to install Jenkins. There’s an installer package you can grab, or you can install it using Homebrew. I choose Homebrew.
From a Terminal window type brew install jenkins.
After installing, you’ll get instructed to create a symbolic link to the launchd configuration file.
Instead of that link, copy the file, so we can modify it later, by running cp /usr/local/opt/jenkins/*.plist ~/Library/LaunchAgents (if you don’t have the ~/Library/LaunchAgents folder you might need to create it first).
Creating a Virtual Server on OS X Server’s Apache
On the Mac running OS X Server open the Server app. It will ask you to choose a server and then login.
Once in, choose Websites on the left menu. On the top-right you have a button to start Apache. On the bottom, there’s a list of Websites. Use the plus button to add a new one for Jenkins.
When editing the Virtual Host, choose a Domain Name such as jenkins.example.com.
If you go to Edit Advanced Settings… you’ll see the following screen:
except that you won’t have the webapp called “Jenkins using ajp13”. Let’s go ahead and create it.
Creating the Jenkins Webapp
Sidenote: OS X Server and Apache configuration files
While you can edit the Apache configuration file for the Jenkins Virtual Host you just created, OS X Server will overwrite it as soon as you make any changes to the Virtual Host using the UI. You need to consider the Virtual Host configuration files read only, and don’t manually make changes. Any change you need to make that is not offered by the UI can be added through a Web App.
Creating the Webapp
Webapps are defined with plist files stored in /Library/Server/Web/Config/apache2/webapps/. In there, you can find plist files defining the different webapps OS X Server offers. There’s a sample one called com.example.mywebapp.plist and you can get the documentation for this by running man webapp.plist.
The plist we1 created for Jenkins looks like this:
You can name this plist whatever you want. The naming convention is reverse URLs. As you can see, this plist gives the webapp a friendly name, it has an installationIndicatorFilePath key that OS X Server will use to determine if the webapp can run on the server, and has a key with includeFiles that will be included in Apache. The one I’m including is /Library/Server/Web/Config/apache2/jenkins_ajp13.conf and its contents are as follows:
What we do here is configure Apache to use mod_proxy_ajp to send some requests to Jenkins running the AJP13 protocol on port 8102.
Adding this webapp to your Virtual Host
In order to add this webapp to my Virtual Host, I had to restart the whole Mac running OS X server, as it didn’t show up on the Webapps panel. Your mileage may vary. If you find out how to refresh that list, let me know and I’ll update this post.
Configuring Jenkins to use AJP13
Remember I told you to copy the launchd configuration file instead of symlinking it? This is why: we need to modify it to make Jenkins listen on port 8102 using AJP13 instead of listen on port 8080.
Here’s how my modified homebrew.mxcl.jenkins.plist file looks:
You can now start Jenkins by running launchctl load ~/Library/LaunchAgents/homebrew.mxcl.jenkins.plist
And that’s it! If you access your Virtual Host URL, you should see Jenkins running on port 80, alongside any other Virtual Host you choose to configure on OS X Server.
Here are my (mainly) unprocessed notes of Apple’s Spring Forward event:
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.
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 developResearchKit in the open1. 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.
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.
Showing a GitHub URL during the event would have nailed it. ↩
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 some1 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.
It never made much sense that the additional 16GB had the same USD 100 price that the additional 32 or 64GB for succesive bumps. ↩
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]1 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 third2 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 offers3.
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.
it’s no coincidence that anytime I think of syncing Vesper pops up. The entire blog series Brent did was a huge inspiration for me, which resulted in more frequent updates to this blog. If you haven’t read it, I highly recommend it. ↩
I don’t know the implementation details, but I guess it’s not really a third database, but flags on the actual CKRecords. This way, if you decide or have to stop Family Sharing, your data could still be part of your Private database. ↩
If Apple ever implements a feature like this, and given that iCloud Deive is claimed to be implemented on top of CloudKit, it wouldn’t be far fetched to think a shared “family folder” could also be added to iCloud Drive. ↩
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 1 for all of us to use, in the form of edit actions and UITableViewRowAction.
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:
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 swipe2.
In case you find it useful, I’ve left the sample project I used for this post a GitHub repository.
Interestingly, in iOS 8, Apple is again testing more UITableViewCell actions, like swiping across the entire row to trigger an action, or swipe from both sides to reveal different options. Additionally, it appears iOS 8 private API also allows you to customize the background colors. I’m looking forward to iOS 9 (or 8.1) making these API public. ↩
As you can see in my sample code, this method has a comment indicating it’s intentionally blank. Any time you need an empty method implementation leave a comment, as these methods will be the first you (or other teammate) will target for removal when refactoring code. ↩