The 9.7-inch iPad Gamevice is Available Now!

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!

The Gamevice for 9.7inch iPads

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.

Tips for iOS-Optimizing Your Website

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:

<meta name="viewport" content="width=device-width">

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:

<meta name="viewport" content="width-device-width, user-scalable=no">

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. 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:

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.

img {
    width: 100%;
    max-width: 640px;
    display: block;
    margin-left: auto;
    margin-right: auto;     

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.

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.

The following code does not work:

        <h1>My Great Article</h1>
        <p>[paragraph 1]</p>
        <h2>Main Point</h2>
        <p>[paragraph 2]</p>
        <p>[paragraph 3]</p>
        <p>[paragraph 4]</p>
    <footer>By WriterPerson</footer>

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.

        <h1>My Great Article</h1>
    <p>[paragraph 1]</p>
    <h2>Main Point</h2>
    <p>[paragraph 2]</p>
    <p>[paragraph 3]</p>
    <p>[paragraph 4]</p>
    <footer>By WriterPerson</footer>

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.

The following CSS fixes this problem:

 .scrollingBox {
    -webkit-overflow-scrolling: touch;

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.

Final Fantasy XI is Coming to Mobile

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 Town Screenshot

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.

Final Fantasy XI Landscape Screenshot

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.

iOS 10 Wishes and Concept Video

Killer article from Federico Viticci at MacStories: a comprehensive wish list of features we’d love to see on iOS 10 – complete with mockup pictures and video!

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.

Big Discount for the Horipad

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.

Picture of the Horipad

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.

‘Low-hanging fruit for Apple and gaming: MFi controllers’

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.

There’s an iPad Pro Gamevice Coming This Year

If you're a fan of the Gamevice, the good news just keeps on coming. Not only is the long-delayed iPad Air version of the Gamevice finally coming this month, but a new 12.9-inch iPad Pro Gamevice is planned for later this year!

A Picture of the Gamevice for iPad Pro

In addition to its larger size, the iPad Pro version seems to have a few additional changes from the other models. According to the tech specs, the Pro version of the Gamevice has a Lightning receptacle instead of a Micro USB port, meaning no more carrying around two cables just to charge your device and controller. Even more importantly, the size of the iPad Pro means that the Gamevice no longer blocks the iPad's headphone jack. This means the Pro Gamevice no longer has its own headphone jack and DAC. Considering how terrible the sound quality on the previous Gamevices was, this is a huge upgrade.

I haven't had a chance to use this Gamevice myself, and I have no idea how far along it is, or whether it actually will be released this year. The good news is, the folks at Gamevice are showing the controller off at GadgetShowLive right now, so there's at least one prototype out there.

For many people - perhaps most - the iPad Pro's 12.9-inch screen is large enough that you can stand your iPad up on a table and enjoy games with a standard Bluetooth MFi controller. Still, there are plenty of gamers out there - myself included - who would still rather hold the iPad in our laps while we play. It's great that Gamevice has a controller for us, and personally, I'm very excited to get my hands on this controller later this year. Assuming it doesn't suffer a massive delay.

The iPad Gamevice is (FINALLY) Coming This Month!

It's over a year late, and months behind its brothers, but at long last it's coming: the Gamevice for the non-mini iPad should be released this month!

The Gamevice for the regular iPad

If you're a regular reader of my site, you know I'm a huge fan of the iPad Mini Gamevice. It's the best MFi controller you can get, in almost every aspect. It's only downside is that it works only with the iPad Mini - one of the weakest devices Apple sells, and a device poorly suited for gaming.

This new Gamevice model takes the same design from the iPad Mini model, but stretches it out to work with the full-size iPad Air and new 9.7-inch iPad Pro. I got a chance to use a prototype a little over a year ago, and it worked great then - presumably it'll work even better after an extra year of development.

Many people have been waiting a long time for this product - I know I have - and I'm glad the wait is nearly over. The Gamevice is scheduled for release this month, presumably as a timed exclusive at the Apple Store; I'll be keeping a look out for it, and I'll post an article when it's available.

Microsoft’s Sexist and Stupid GDC Party

Microsoft, apparently forgetting that it’s 2016 and not 1996, thought it was appropriate to have “erotic schoolgirl dancers” at their GDC party.

I thought we were past this crap. The whole “booth babe” concept has always been offensive, pandering, and sexist. It took a while, but the world finally seemed to wake up to that fact within the past decade. Where was Microsoft?

I cannot imagine the reaction if Apple did something like this.


The guy who should probably be fired for allowing this to happen issued a half-hearted apology:

Phil Spencer says:

At Xbox-hosted events at GDC this past week, we represented Xbox and Microsoft in a way that was not consistent or aligned to our values. It was unequivocally wrong and will not be tolerated. I know we disappointed many people and I’m personally committed to holding ourselves to higher standards. We must ensure that diversity and inclusion are central to our everyday business and core values. We will do better in the future.

GDC 2016: My Impressions

Picture of a huge crowd at GDC

The second day of GDC is upon us. Tuesday; the calm before the storm, since the main expo floor opens on Wednesday.

I've walked the halls of the conference, listened to 5-10 talks and presentations, and checked out all the currently-available booths. Obviously much of the conference is still locked behind closed doors until Wednesday, but a few things stick out clearly from the preliminary exhibits:

VR is the Hot New Thing

Right from the start, one thing is abundantly clear here at GDC: VR is everywhere. Mobile VR, desktop VR, console VR, AR, cardboard-style VR - literally every form of VR you could imagine is on display at practically every booth.

The Whirlwind VR headset

Interestingly, the approach each parties are taking to VR and AR are wildly different from one another. We have $10 cardboard VR devices that hold your phone up to your eyes, and right next to that, we have thousand-dollar high-end rigs designed to work with PCs. There's some gimmicky stuff - one VR headset has a fan that blows air on your face while you play - but the vast majority of VR systems are gunning for mainstream popularity.

A player in a racing chair

Throughout the conference, I'll be doing my best to find as much mobile-gaming-focused content as possible. Maybe I'll get lucky and find some controller-based news. But one thing is becoming increasingly clear: I'm probably not going to find much hardcore mobile-gaming-related news that doesn't incorporate VR in one form or another.

Apple is Everywhere and Nowhere.

Apple has never had an official presence at GDC, but that doesn't mean they aren't here. In my cursory glances at people's GDC badges, I've seen a lot of people with Apple on their badges.

I'm sure some of these folks are gamers who just so happen to work at Apple; Apple employees are people too, after all. But when there's smoke, there's fire. The sheer number of Apple badges I've seen suggests Apple might have sent people to at least visit the conference.

A talk on copycats and clones - I hope Apple was watching

This many Apple employees have to be doing something here. Maybe just taking in the sights. Maybe just keeping an eye on the latest mobile games.

Whatever they're doing, I'm happy to see Apple with some sort of presence here. Apple has a lot of blind spots when it comes to gaming. Listening to, meeting with, and talking to some of the smartest people in the games industry can only help Apple do a better job. If enough developers gripe about how terrible the App Store is for making a sustainable living designing games, maybe it'll get through someday.

Mobile is Missing

Perhaps the most surprising aspect of this conference: the complete lack of any form of mobile gaming. I've seen between 5 and 10 completely different VR devices, and yet I haven't seen a single iPhone or iPad. 
Chillingo has a booth! But no games

The only mobile devices of any form I've found are a few Intel tablets and smartphones, and that has more to do with Intel's desire to push for X86 smartphones and tablets than it does for an actual desire to talk about mobile gaming.

There are a few possibilities here. There's a longstanding stigma from so-called "real gamers" against mobile gaming, and perhaps this discourages indie developers from showing off the mobile versions of their games. There's also the idea that mobile is no longer the hot new thing - that's VR - so it isn't worth showing off.

The one smartphone: an Intel VR demo

There are multiple panels and conference talks about various aspects of mobile gaming, but the lines for these talks are far lower than those for VR gaming. From my perspective, this is insane. Mobile is the biggest game platform in the history of gaming, and ignoring it in favor of a technology that is at least a year out seems shortsighted.

The Train Jam tasked players with building a PC game during a train ride

The Future

The good news is, the actual GDC expo hasn't started yet. That comes Wednesday. Monday and Tuesday are made up of lectures, discussion panels, and lobby exhibits.

The actual expo will have more presentations from the big name companies. Sony, Microsoft - you know the big guys. It's possible that something more mobile-focused will be shown off in the exhibit hall. I'll continue to keep my eyes open.

This is my first GDC, and it seems like I picked an odd one to start with. There's a feeling in the air that VR is the next gold rush. In the next few years, this prediction will either be proven true or false. We're right on the precipice of this new media, so that's all anyone is talking about.