WWDC is upon us once again! Lots of new things to unpack – major new features for iOS, , tvOS, watchOS, and (don’t call it OS X!) macOS.
First up, and perhaps most important for this site’s audience: games for the Apple TV can now require MFi controllers! No longer are they limited to the inputs of the Siri Remote. Games that really only work with a full controller layout – console ports, hardcore platformers, shooters – can now require MFi controllers.
In the lead-up to the Apple TV launch, I said Apple was right to prevent tvOS games from requiring MFi controllers. At this point, it’s pretty clear I was wrong. I’ve been wondering why that is. Here’s what I think:
It’s safe to say that the Apple TV launch didn’t exactly go as planned for Apple or for developers. Everyone was hoping this platform would gain widespread adoption among causal users. This hasn’t happened. The Apple TV is still a niche product. It’s too expensive. It overlaps functionality built in to most smart TVs. It launched without a compelling exclusive video streaming platform.
If the Apple TV was a mainstream product, allowing developers to require expensive third-party controllers would be stupid. It would fragment a market during its initial launch – exactly the time a platform needs to be unified. However, the Apple TV is not a mainstream product. It’s a product for early adopters, and for people who are willing to pay a massive premium for a better experience. If the Apple TV is already a niche product, allowing MFi-controller-exclusives makes a lot of sense. You’re already dealing with an audience that is outside of the mainstream.
Importantly, apps for iOS and macOS can not require MFi controllers. Those are mainstream platforms – Apple can’t afford to splinter those markets.
Still, this optional controller requirement is good news for iOS gamers. It might lead to greater developer adoption of MFi controllers across-the-board. At the very least, it should allow games like Minecraft and Grand Theft Auto to be ported to the Apple TV with much less difficulty.
Big, big news for iOS gamers: Apple is in the middle of rolling out MFi game controller sections to all of their retail stores! You read that right – if you head down to the nearest Apple Store, you’ll probably be able to play with any of the current top-tier MFi controllers, right now. Most Apple Stores opened these gaming sections yesterday; the rest will be rolling them out throughout the week.
Apple is giving iOS gaming its own featured section, sometimes even with a hands-on area
Every single Apple Store – all 465 locations – will be receiving a dedicated “gaming” space, highlighting the best available MFi controllers and recommended accessories. You’ve been able to buy MFi controllers in Apple Stores before, but they’ve never been collected together and presented as a platform before – this is a big deal for the ecosystem.
To be clear, this is a world-wide rollout, and it hits every single store, from the biggest flagships to the smallest mall outlets. Every Apple Store, everywhere, will have every top-tier MFi controller in-stock and in a dedicated section.
Apple seems to be promoting the Gamevice in a big way
Giving gaming its own section is good, but it gets better. In addition to the gaming sections, many of the larger Apple Stores will feature usable Gamevice controllers, out of the box, connected to iPads loaded with games. This is important; I’ve always said that the most important thing Apple could do to promote MFi controllers is to actually let people use MFi controllers. Once gamers get a chance to play Minecraft on an iPad Mini connected to a Gamevice, the controller will sell itself.
Many Apple Stores already had the Horipad Ultimate and SteelSeries Nimbus controllers hooked up to the Apple TV. While that is great for TV gamers, but it doesn’t make it clear that these controllers work with iOS. This new section fixes that problem, and presents tvOS and iOS as a unified gaming platform – a great move, considering the iOS audience is tens of thousands of times larger than the Apple TV audience.
Gaming is a defined section, separate from other accessories
I was curious about how knowledgeable Apple was about these controllers – when the MFi controller program first started, Apple retail employees generally had no idea what the controllers were. Chatting with a couple of the Apple Retail employees at the new Union Square Apple Store eased my worries – these people know a lot about MFi controllers. More than that, the people I talked to were enthusiastic iOS gamers – one employee was very much looking forward to the iPad Pro Gamevice for personal use.
This push with Gamevice represents one of Apple’s biggest commitments to the MFi controller program. Not only are they promoting a product exclusive to iOS, but for the first time, they’re stocking every single available Gamevice in every Apple Store – the iPhone, iPad Mini, and standard-sized iPad models are all available, with the iPad Pro model coming later this year. It’s a welcome sight, and I hope it’s a sign of things to come.
I just arrived back in San Francisco for WWDC, so of course the first thing I did was visit the new Union Square Apple Store.
The new store is amazing, and probably warrants an in-depth review of its own. But of special note to readers of this site, the store is host to a few MFi controllers you can’t easily get anywhere else. There’s the 9.7inch iPad Gamevice, which is only available online and in this store. And – of special interest to readers of this site – an exclusive MFi controller: a white version of the SteelSeries Nimbus.
The Nimbus, now in white
I’ve been wondering about this controller since it was first hinted in blurry photos from press visits to the store’s soft-launch. I was expecting to see this controller roll out to additional Apple Stores in the weeks after the Union Square store opening. Instead, SteelSeries was completely silent about it. I wasn’t expecting a full ad campaign extolling the virtues of a white controller, but I was at least expecting a mention on the SteelSeries website. Alas, nothing – I definitely needed to check things out for myself.
After chatting with the gaming expert at the Apple Store, I have a more clear picture of what’s going on. Turns out the white Nimbus controller is exclusive to this specific Apple Store location. If that isn’t enough, SteelSeries only made a few hundred of them. So if you want a white Nimbus, act fast. And… I guess, book a flight to San Francisco.
But do you really want one? I’m not going to do a separate review for a color variation – my review of the regular SteelSeries Nimbus mostly stands for the white variation – but there are a few things about this model that are worth mentioning.
The most important thing: this white Nimbus is very clearly just the black version with a coat of spray paint. And not particularly good spray paint, at that. I was able to scratch off a bit with my fingernail, revealing the standard black plastic beneath.
Due to the extra layer of paint, the surface texture of the controller is noticeably less “matte” than the black version, and as a result, feels much cheaper. The feel falls somewhere in the gray area between matte and glossy – it feels far more like a decent Chinese knock-off controller than it does like a premium Apple-exclusive product.
The Two Nimbuses; notice the surface texture differences
The coat of white paint on this Nimbus has another unfortunate side effect: it makes the entire controller smell strongly of chemicals. Seriously – I’m not usually affected by this type of thing, but upon opening the box, I was hit by an overwhelming smell that reminded me of white-out fluid. I’m assuming this is left over from whatever they did to color the surface of the controller. Whatever the reason for it, I had to leave the controller sitting at an open window all night before the smell faded enough for the controller to be usable.
The controller I purchased has another problem, and unfortunately, this one goes far beyond cosmetics. The A button is extremely sticky. I have no idea whether or not to chalk this up to the paint job – none of the black Nimbus controller I’ve used have this problem – but it’s kind of a big deal, the problem doesn’t disappear after using it for a bit.
The last thing I have to point out is the price: for this limited-edition white (painted) Nimbus, you’ll have to shell out $59 dollars. That’s a significant premium over the standard Nimbus, which is currently on sale for $41.99 on Amazon (with free shipping!).
The white Nimbus looks cool, but is poorly executed and overpriced
If you want a white Nimbus, you have a couple of options. You can make a trip to San Francisco, visit the Union Square Apple Store, and shell out $59. Or you could visit Amazon.com, order a black Nimbus and a can of spray paint, and make your very own white Nimbus controller. Whichever option you choose, you’ll wind up with the same thing.
Shooter fans, be warned: Spartan Strike isn’t a traditional Halo game. Microsoft’s mobile Halo games are top-down action-strategy games, and play more like a sci-fi Diablo than a first-person shooter. Don’t let that turn you off, though. These are excellently designed games, with high production values, relatively short missions that lend themselves well to mobile gaming, and full MFi controller support.
Spartan Strike is a very different Halo, but still fun
On a higher level, I think Microsoft’s iOS software (and gaming) strategy is fascinating. As Microsoft’s priorities have changed, their treatment of iOS has shifted dramatically. The Halo games are a great example of this.
The mobile Halo games were originally released years ago, for Windows Phone 7. By using the familiar Halo license and including Xbox Live Achievements, Microsoft hoped these games would make the Windows Phone platform attractive for Xbox gamers. This didn’t work, and for a variety of reasons beyond the scope of this blog, Windows Phone was a catastrophic failure.
Now, Microsoft’s is transitioning into a services company. This change of focus realigns Microsoft’s interests – suddenly, instead of using exclusive software as a draw to get people to use their hardware and OS, Microsoft benefits from getting their games and apps on as many platforms as possible.
From that perspective, Halo on iOS makes perfect sense. Microsoft gets access to Apple’s huge audience, they get to expose the Halo brand to gamers who might not own an Xbox, they get to push Xbox Live (and it’s achievements) on gamers who might have only used Game Center. It fits.
With the relative failure of the Xbox One, and Microsoft’s changing priorities regarding services vs hardware lock-in, I wonder if these games might be the first of many Xbox licenses we’ll see on iOS.
It’s finally here! About a year behind schedule, but at long, the time is upon us: the 9.7 inch iPad Pro / iPad Air version of the Gamevice is available right now from the Apple Store!
THIS is the controller you've been waiting for
Mine arrives tomorrow. I’ll have a review up shortly thereafter. I’m expecting my opinion of this Gamevice will closely mirror my opinion of the iPad Mini Gamevice – and I still think the iPad Mini Gamevice is the best MFi controller you can get.
Viewing the web through a pocket-sized screen is a different experience than viewing it on a massive desktop screen. It deserves an experience optimized around it. Unfortunately, mobile webpages often come up short, especially when compared to their desktop counterparts. From the very beginning, I designed AfterPad specifically for mobile – The iPhone was the target size, and the iPad and computer versions were modifications to the iPhone UI.
This comes with a number of weaknesses – I’d really like to have a few more tabs on the top of the site – but it also comes with strengths. When iOS is your primary platform, you can throw away a lot of legacy “best practices”, AND take advantage of some iOS-exclusive features.
Throughout the process of building AfterPad, I’ve found some handy tricks to make the site feel a lot more “at home” on iOS. I am not, by any means, a master web designer, but I figured I should share some of the techniques I use.
This is not a complete guide to web design, or even a complete guide to mobile web design. But it does have a few cutting-edge tricks that a lot of web designers might not be aware of.
Set your Viewport equal to device-width
This is a basic step – definitely not a cutting-edge trick – but any guide to making a mobile-friendly site wouldn’t be complete without it.
Mobile Safari was designed for an era of desktop websites. Because mobile versions of websites didn’t exist when the iPhone was released, Apple employed a clever trick to make standard websites look good. By default, Mobile Safari creates a fake screen that’s 1024 pixels wide, renders your page inside this fake screen, and allows people to zoom in to see the full content.
This is how the iPhone displays the “full Internet” – it emulates the size of a traditional computer monitor. This makes a ton of sense for sites that are designed assuming most people’s monitors are 1024 pixels wide. But for mobile themes, you need to address the real width of the iPhone screen.
The following code, in the head section of your HTML, turns off Safari’s fake desktop rendering:
If your website is designed to emulate an app-like experience, or if it uses fixed-position elements, you can go further than this by preventing users from zooming your page.
To prevent zooming, use the following meta code, instead of the above:
If you decide to prevent visitors from zooming in on your site, you need to be extra careful to make your site’s text readable, especially for people with vision problems. You should definitely implement the next trick:
Take Advantage of Dynamic Type
This is a new trick. Very few websites take advantage of it, which is a shame, because it’s one of the most important features to ever come to Mobile Safari.
With iOS 8, iOS introduced Dynamic Type, a system-wide way for users to control text size. Not only does this provide a great way for users to personalize their reading experience, but it also acts as an accessibility control, allowing far larger text sizes for users with vision problems.
Safari traditionally didn’t need this, because it was possible for users to zoom-in and magnify text they wanted to read. However, many mobile websites opt to block zooming, making for a more native-feeling experience, but one that can be difficult to read for people with vision problems.
If your mobile site blocks zooming, you should implement dynamic type. You may think you know best about text sizing, but for people with accessibility concerns, you probably don’t.
To implement dynamic type, add the following rule to your CSS. It can be used site-wide, specifically for paragraph elements, or anywhere in between. This example assigns it site-wide to the body element:
body {
font: -apple-system-body;
}
Because this code must be assigned to the “font” shorthand property, it changes both the font-size AND font-family properties. Unless you want to use Apple’s San Francisco font on your website, you need to add the font-family rule below the “font” rule, which overrides San Francisco with the font of your choice.
Keep in mind, if you’ve assigned dynamic type to a parent element, you can override it for a child element by assigning a font-size to the child element. If you use em units to define the size of child elements, they’ll even scale according to the user’s dynamic type setting!
Consider Using iOS-Native Fonts
I know that bundling “premium” web-fonts is popular, but they come with downsides. They take time to download. During that time, you can either display nothing – your text is blank for a second or two, then blinks in all at once – or you can display a fallback font – your text shows up using a native font, then switches awkwardly to your fancy one after the fancy one finishes downloading.
The good news is, you might not need to do either of these. The font situation on iOS is better than you think. Apple bundles several excellent fonts with iOS, and you can use them all on your website with zero performance penalty and zero license fee.
iOSFonts.com keeps track of every font available on iOS, and let’s you see which fonts are supported by each version. If you happen to like any of these fonts, you don’t have to any special tricks to use them: simply add the font name to your “font-family” property.
body {
font: -apple-system-body;
font-family: "Avenir Next", "GillSans-Light", sans-serif;
}
Note: if you’ve taken advantage of the dynamic-type feature mentioned above, you’ll need to place your font-family rule below your dynamic type font rule.
Prevent Automatic Text Resizing
Mobile Safari likes to resize fonts. In the early days of iPhone web browsing, websites weren’t optimized for small screens. The iPhone would show you a shrunken-down version of the desktop site, and you’d zoom-in on the part you wanted to read. To make it easier to see what you’re zooming-in on, Safari would magnify the text in paragraph blocks, often making the body of an article larger than its heading.
If you’re hand-tuning your site for mobile, your text should already be optimized for reading on a mobile device, and you might not even allow zooming.
To prevent Safari from automatically resizing text, add the following rule to your CSS:
body {
-webkit-text-size-adjust: 100%;
}
Note: this rule is unrelated to whether users are allowed to zoom, and has nothing to do with dynamic type. If you allow zooming, visitors can still enlarge text by zooming in. If you’ve adopted iOS dynamic type, font size will still be influence by the global dynamic type iOS setting.
Use 16px font-size for Text Boxes
This is a lesser-known requirement. If your website uses a text box where visitors input text – for a search field, a forum post composition field, anything like that – set the font-size of those fields to 16px.
If you don’t do this, Safari zooms in every time your visitor taps on the text field – it really wants text-input fields to be 16px, and it’ll magnify things until it gets its wish. It sometimes does this even with zooming turned off, and the default viewport set to device-width.
Use the following code to make Safari stop zooming-in when visitors select a text box:
textarea,
input,
select {
font-size: 16px;
}
This is one of those little things that makes a big difference.
Use max-width and width Properties for Images
This is one of the quickest and most effective ways to make a mobile-optimized version of your site. It’s most useful on blogs. On mobile version of most blogs, embedded pictures look best when they’re the full width of the iPhone’s display, possibly with a small margin. On desktops, with much wider displays, these pictures would look far too big.
There’s an easy solution: instead of using the width property to control the width of your images, use max-width. Then set the width to 100%. Then, if you want to center the images, set the left and right margins to auto and the display mode to block.
The above code will make every image the full width of its container, up to a maximum of 640px wide. Any wider than that, and the image will be centered, with margins filling the difference. These are the exact values I use on my site. The same trick can be used for any element – quote blocks, videos, paragraphs of text. This is an essential tool for making a responsive mobile site.
Customize the Tap Highlight Color
Web designers often use JavaScript touch events to customize the tap behavior of buttons and links. This works, but it never feels quite right – it tends to trigger when you inadvertently tap something while scrolling, which looks jankey and feels out-of-place.
You might be able to get away with customizing iOS’ standard tap highlighting instead. The following code changes color of the box that appears when you long-press a link to red:
a {
-webkit-tap-highlight-color: rgba(255,0,0,0.1);
}
Note that the tap highlight appears over the link, meaning it must be slightly transparent, or it obscures the link.
AfterPad uses only the -webkit-tap-highlight-color property to control the appearance of selected elements. By combining it with padding, it’s possible to have somewhat native-feeling list boxes, without the overhead of using JavaScript.
Optimize for Safari’s Reader View
Safari Reader View is a tool that allows website visitors to see just the content of an article, with none of the cruft. You might not like the idea of people stripping out all the sidebars and navigation tabs (and ads) from your site and just viewing the text, but the fact of the matter is, people do it. And if your site looks broken in this view, you’re the one who looks bad. The good news is, the tricks here will likely increase your search position in Google, and should also make your site easier to read in Instapaper, Pocket, and Readability.
The most important thing you can do to make your site work correctly with Reader View is make sure your site is built on well-formed HTML. Writing good HTML is outside the scope of this article, but the basics are important.
Don’t have multiple h1 tags in a single article element.
If you aren’t using article elements, don’t have multiple h1 tags at all.
If you screw these things up, Safari might not know what the title of your post is supposed to be, and it could make the mistake of assuming one of your sub-headings is the title.
Another major rule: Reader View will generally only work for articles with a minimum of around four paragraphs. Any less than that, and it doesn’t usually show up.
There’s one extra rule that screwed my site up for a long time: you can’t wrap the content of your article in a container. Your h1, h2, or header elements MUST be in the same container as the p tags that make up your article.
If you write the above code, Reader View will think your article is titled “Introduction”. That’s because the h2 header containing the word “Introduction” is the first heading element inside the box that contains your p paragraphs – in this case, a section element.
The above code will probably work. Because there is an h1 element inside the same block article with all the p paragraphs, it will be assumed to be the title of the article.
Still, Reader View is a mysterious and fickle beast. Even if you take advantage of the above advice, your articles still might not work correctly. But if you don’t take advantage of this advice, they almost certainly won’t work. Take this advice as a starting-off point.
Allow Smooth Scrolling in Scrollable Elements
By default, Mobile Safari is designed around the idea that when you drag your finger on the page, no matter where your finger is, the entire page scrolls. This is a perfectly reasonably assumption, but sometimes it doesn’t hold up. If you have a site with a separately scrollable element – say, a sideways-scrolling image box or a vertical-scrolling description view – you’ll need to employ an extra trick to make scrolling work correctly.
The traditional way to make a scrolling element is by setting overflow: scroll on that element’s CSS. The problem is, if you just do that in Mobile Safari, scrolling feels very wrong – there is no bounce, no acceleration, and no smoothness.
If you add this code, scrolling in subviews will feel just as smooth as scrolling in a native app.
Don’t Beg People To Install Your App
Look, I get it. You’re proud of your app and you want people to use it. You know how much better it is than your website. You know how valuable it is to be installed on someone’s device. You know that if you don’t get a reader to install your app right away, they might forget. You know that if your site uses ads, some of your visitors are blocking those ads. None of this matters – you still shouldn’t irritate visitors about installing your app.
If your website is terrible, visitors are likely to assume that your app is also terrible – why on earth would anyone install it? Would you? It’s far easier to build a website than it is to build an app – if you can’t even build a good website, nobody is going to install your app, no matter how much you beg them.
If you have an app, and you absolutely must tell your visitors about it (like if your site only exists to support your app), there’s one way you should do it: using the official APIs provided by Apple and Google.
I’m not going to get into the details here; Apple provides a great website with more information on how to do this.
Users hate app pop-ups. Google has recently started penalizing sites that don’t take advantage of the official APIs. Do the right thing here.
I’m actually surprised about this one: Final Fantasy XI is coming to mobile in the near future!
Nexon appears to be handling the porting job, although Square Enix handled original development. The entire game has been remade in Unreal Engine 4 – an engine that has already yielded impressive results on iOS. Based on the (admittedly low-resolution) available screenshots, Final Fantasy XI should not disappoint.
Final Fantasy XI definitely looks the part of a Final Fantasy MMO
Final Fantasy XI is interesting in that unlike all previously-released Final Fantasy games, it’s an MMORPG, not a single-player experience. Considering that there are relatively few MMOs on iOS, that alone should make this one worth a look.
The lighting and shadows look far better than the textures and models
We still have no idea if Final Fantasy XI will be translated to English, let whether it supports MFi controllers. Considering Square Enix’s record, I’m optimistic. I’ll be looking forward to learning more about this one as it gets closer to release. Because of the difficulties of running an MMO, I was actually expecting Square Enix to skip this one on iOS; from that perspective, ANY news is good news.
Seriously, I’m not even going to excerpt my favorites here. Read the whole article, it’s great.
I’d add a few feature requests of my own to the pile:
Selection that actually works. This is a longstanding issue I have. When I try to select text on a webpage, iOS pretty much makes up its own rules for what is getting selected. These rules change arbitrarily depending on how zoomed the page is. It’s been 10 years, this needs to be fixed.
Mac-style Spotlight Search. The search interface called “Spotlight” in iOS is vastly inferior to the Mac version – it only works from the home screen, it doesn’t search the same amount of content, and it only has a limited degree of quick actions.
We’re seeing progress on this front – iOS 9.2 added keyboard navigation to Spotlight results, and allowed you to launch the top result by hitting the Enter key. We have further to go. There’s no reason Command+Space search on iPad should be worse than Mac.
Safari Technology Preview. I’m convinced this is coming. Apple recently released a special version of Safari for Mac that acts like a snapshot of work-in-progress features. This app would actually make even more sense on iOS, since it would have the side benefit of allowing two versions of Safari to run side-by-side in split-screen multitasking.
Expanded Hardware Keyboard Support. There is still much low-hanging fruit to harvest before the iPad can be taken seriously as a full Mac replacement – this falls under that category. Hardware keyboards can’t be remapped in iOS right now – if you’re using a PC keyboard, the Command and Option keys are reversed. If you like setting Undo+Cut+Copy+Paste to F1+F2+F3+F4, you can’t. Forget about more advanced macros. This is easy to fix – Apple can bury these settings under Accessibility, but they should be there.
Better Command+Tab App Switching. The iPad throws up a Mac-style app switching overlay when you press command+tab on a hardware keyboard. This makes no sense – iOS already has a superior native app switching interface. Allow keyboard navigation of this interface instead of remaking the Mac version.
Trackpad Support. This is a big one. I know it has been heavily debated inside of Apple. The ground work is already in place – you can already use the virtual keyboard as a rudimentary trackpad on iPads and 3D-Touch-capable iPhones. It’s time to throw the switch on this one. Get trackpad support out there, let developers and users figure out the use case and iron out the bugs. This doesn’t come at the expense of a touchscreen, of course, but it should be there.
Full-quality HDMI Out. I don’t believe there is a technical limitation to why the iPad Pro can’t output a full, uncompressed HDMI signal from the HDMI adapter. Previous devices had to compress the video via H264 and output it to a special computer buried in the adapter. That computer then decompressed the video and output it over the HDMI connection. This was done to work around bandwidth limitations in Lightning.
The iPad Pro probably doesn’t have these limitations. At USB 3 speeds, it should be more than capable of outputting native video. This is probably a very low priority, but it should be there.
Local Backup Via Time Capsule. Apple sells a wireless base station with a built-in backup drive. The Mac can wirelessly back up to this drive, but iOS cannot. With all the horror stories about privacy and government intrusion in the news these days, a lot of people would probably pay for a good quality, transparent, local backup.
Fix Copying. Seriously Apple, this is a bad bug. When you copy something, it should copy. Always. Somewhere in the past few months, that stopped working some of the time. Fix that.
Amazon has the original Horipad MFi controller on sale for $49 – $30 less than it’s usual price.
The Horipad is an excellent controller. At the time of my in-depth review, it was my favorite MFi controller available. It’s excellent d-pad makes it a great choice for retro gamers, and it’s 4 rear shoulder buttons makes for a perfect controller for PlayStation-era games.
The Horipad is an excellent PlayStation-style controller
The newer Horipad Ultimate controller is probably a better choice for most people, but the original is also excellent. Both are among my favorite MFi controllers.
If you’ve been waiting for a price drop on the original Horipad, and you prefer it’s circular d-pad and four shoulder buttons to the newer Horipad Ultimate’s plus-pad and triggers, now is a great chance to pick up a great controller.
Craig Grannell lays out some of the ways in which Apple botched the MFi controller program, and some of the ways they could improve it.
The original MFi controller release was a mess. Apple seemingly didnât understand that it was splitting the iOS ecosystem into two camps â games with or without support â and then fragmenting it further, due to offering alternate controller specs. The âstandardâ controller has a D-pad, four face buttons, and two shoulder buttons. The âextendedâ controller adds two more shoulder buttons and analogue sticks. Oddly, the industry standard Start and Select buttons were omitted entirely (in favour of Pause, recently itself replaced by Menu on controllers designed for Apple TV), which I have on good authority very much annoyed several developers.
In retrospect, including reduced-layout “Standard” controllers in the MFi controller program seems like a mistake. I don’t particularly care about the absence of Start and Select (and L3 and R3), but Apple should have stuck to a consistent layout.
