a blog on technology, music and geek culture from room34

Main menu

Tag Archives: iPhone

Post navigation

Here’s my early review of Super Mario Run, less than a day after it was released.

I think I like it.

I have been waiting forever for Nintendo to finally accept the reality of modern mobile devices and make games for the iPhone. (No, Miitomo doesn’t count. And Pokémon Go doesn’t really, either, especially since Nintendo didn’t actually make it.)

There have been a ton of Mario-inspired platform games for iOS over the years, and while many have been of very high quality and creativity, none has stuck for me.

What makes the top-tier Nintendo franchises (and here I am thinking Mario, Zelda, Metroid, and maybe Pokémon) so great? These are the criteria:

Engaging concept

Attention to detail

Playability

Platform-optimized experience

Every would-be Mario surrogate on iOS has failed at least one of these criteria. And I expected that, if Nintendo ever did make an iOS game, especially a Mario game, when it finally did arrive it would be an unmistakably “Nintendo” experience because it would nail them all… and most likely differ from what I thought I wanted about the experience, because what I thought I wanted wouldn’t really work, and what I actually wanted was something I couldn’t quite imagine.

People have been saying it for years, but yes: this is how Nintendo and Apple are alike, and why I expected to be surprised, if not amazed, by what Nintendo came up with, even if it didn’t seem at first glance like it would be successful.

The biggest surprises for me about Super Mario Run when it was announced were a) how slow Mario seems to run, and b) that it’s essentially an endless runner with one control: tap-to-jump. It’s like the old joke before the iPhone came out that, if Apple ever released a phone, it would only have one button. Guess what: it did, and it changed everything.

Let’s explore the criteria, one by one:

Engaging concept. It’s classic Mario. The basic formula that has existed since Super Mario Bros. in 1985. More specifically, this game, visually and structurally, fits very much into the mold of the New Super Mario Bros. series that debuted about a decade ago on the Nintendo DS. Check.

Attention to detail. This feels like a Nintendo game, in all of ways, both good and bad. The good is where it counts — the actual game experience. The bad is the surrounding stuff, showing that Nintendo is still out-of-step in the online world. First, the bad: this game requires an always-on Internet connection, which seems a bit ludicrous. Apparently the primary reason is to prevent piracy, which I really don’t get. The only way to pirate iOS games is to jailbreak the device, and it seems like there would be easy enough ways for the game to detect that without an Internet connection.

Besides the Internet connection issue, there’s also the fact that the initial setup process requires selecting your country from a huge list (again, this is something the game should be able to detect automatically, especially since it has to be online to function) and a distracting Nintendo Account step. Then after a brief gameplay tutorial, you’re thrust into a black screen with a progress bar as the full game content is downloaded. I’m not sure if my experience was just due to peak interest at the launch, but it took forever to download… in fact, I tried over four sessions as I was out-and-about, jumping between LTE and WiFi in various locations, until I finally got the last 5% to download when I was at home several hours later.

So, that’s the bad, and it really kind of sucks. But the good is, once the game is actually loaded up on your device, it has all of the polish you expect in a top-tier Nintendo title. The design is flawless, the UI interactions are smooth as can be, and everything about it shows the same level of care that Nintendo puts into the best Mario games for their own systems. And because the iPhone screen resolution is so much better than on a DS/3DS, this looks much more like a Wii U game than a mobile game.

Playability. This is where I was really surprised. At first I was disappointed. Mario runs continuously, which makes sense for the one-hand — really, one-finger — control scheme, but he seems slow. This is not the “hold down the B button” running we’re used to in a Mario game. It’s about halfway between his usual walking and running speeds. But you quickly realize the speed was carefully calibrated for optimal playability. When you don’t have the ability to make Mario stop, you need just a fraction of a second longer to figure out how best to react to what’s going on in his environment. Before long you realize this speed feels perfect in conjunction with timing jumps, interacting with special blocks and avoiding enemies.

Speaking of enemies, when Mario is running and approaches an enemy, he automatically vaults over it. It’s a cute effect, but initially it made me wonder… is there any way to die in this game? Especially since it seems like even when Mario would die, such as falling down a hole, he instead goes into a bubble (as in New Super Mario Bros. U) and gradually floats backwards on the course? Well, yes. I didn’t immediately realize that you have to earn those bubbles, and they eventually run out. Plus, Mario only vaults over enemies if he’s running. If you’re mid-jump and he touches an enemy (other than landing square on its head), he dies just like in any other Mario game.

After a couple of easy screens, the complexity of the courses quickly catches up with you, and before you know it you feel like you’re just playing a regular Super Mario title, not a streamlined “endless runner” version.

Platform-optimized experience. Speaking of that streamlined “one-finger” control: one of the most irritating problems with any iOS game, aside from the difficulty of using a simulated, on-screen D-pad for movement, is the fact that your fingers obscure part of the screen. Nintendo, of course, solved this perfectly. When you’re navigating the game interface, the full screen is used as in any other game. But during a run, the bottom 1/4 or so of the screen has no action… only a generic background design matching the style of the current course. That way, you can keep your thumb poised at the bottom of the screen ready to tap (or tap-and-hold for a longer jump) without covering up any of the action.

I would never have expected a one-control, endless-runner style Mario game to work as a real Mario game, but it does, and is probably the only way to make this work on an iOS device. But Nintendo not only defied most fans’ logic with this control scheme, they perfectly tailored the elements of the game to work with it. They removed standard elements of Super Mario games (like Fire Flowers) that simply wouldn’t work with this control scheme, and they added things that — while they maybe would work with a traditional control scheme — are only logical with an endless runner, like special blocks that make you change direction when you jump on them, and others that pause the action to give you an extra moment to decide how to proceed.

A couple of other realities of mobile devices that Nintendo acknowledged with this game’s design are the brevity of play sessions and the interest in online competitive play. The levels here are shorter than typical Mario levels, although they don’t feel especially short, but they work well if you only have a minute or two to play. And the Toad Rally mode is a great way to do online competitive play. You’re not actually competing in real time, but the game makes it feel like you are, by matching you up with actual previous runs by other players.

There’s also a reward system for daily play, unlocking both useful features like additional playable characters as well as more frivolous prizes like decorations for your Mushroom Kingdom, similar to some of the features in Miitomo. And of course, you can tie in your Nintendo Account so your Mii shows up throughout the game. (I assume some of what you do here feeds back into the Miitomo experience as well, but to be honest I deleted Miitomo off my iPhone months ago.)

Overall… yes, I do think I like it. This is not the perfect classic Super Mario experience I always thought I wanted on my iPhone, but… let’s be honest. There are enough other, really well-done iOS platform games out there that I have tried for a day or two and then abandoned that I realize a perfect classic Super Mario experience is impossible on a touchscreen device with no physical controls. What Nintendo has delivered is a new kind of Super Mario experience that feels 100% “Mario” but actually works on an iPhone.

Now, what I really want them to do is an iOS Zelda game. There are Zelda DS games that rely almost entirely on the touchscreen and stylus for all movement and action. It seems like a no-brainer that this experience would translate well to a mobile phone. But then, what do I know?

I’m working on a site right now that has a fixed, full-bleed (i.e. background-size: cover) background image on the <body>. The content flows over it, mostly obscuring it completely, but the background is occasionally revealed in the spaces between content blocks. Some blocks have a semi-transparent background so you can see the fixed background as if through frosted glass.

It’s a cool effect, but it really, really does not want to play nicely on mobile. Various odd things happen on both Android and iOS, and they are completely different.

Quick side note: Yes, the background image is a JPEG. Normally I only use PNG or SVG images in UI elements, but I had good reason to use JPEG here: even though it’s only two colors (with some in-between colors due to antialiasing), the pattern in the background is incredibly complex, and a JPEG version of the file is about 1/5 the size of the PNG. And since it’s an illustration, I tried making an SVG version first, but the pattern is so large that the SVG was about 2 MB! So JPEG it is… which may be a factor in the issue I’m having on Android, but I haven’t tested a PNG version of the image to verify that.

iOS Problems

I’m an iPhone user, so I mainly test responsive sites on iOS. I do own an Android phone (a Motorola Moto E, which I highly recommend as a cheap-but-decent Android phone for testing), but I generally only break it out during the final round of browser testing prior to launching a site.

The issues with background images on iOS are well-known to most web developers. iOS has a number of rather arbitrary seeming limitations imposed upon the Mobile Safari browsing experience, generally for one of three reasons: 1) performance, 2) touch interface usability, 3) the whims of the ghost of Steve Jobs. In the case of background images, background-attachment is not supported. I’m not really sure how this would impact either (1) or (2) — although I think with the early underpowered iPhone generations, it did impact performance — so I think we’re dealing mostly with (3) here. At any rate, because you can’t have an attached background on iOS, I added this in my media queries:

Another quick side note: Why is my phone break point at 782 pixels, you ask? Because that’s where WordPress has its break point for the admin interface. I’m not exactly sure why the WP team chose that number, but why fight it?

Besides the background attachment, there’s also the issue that background-size: cover on a phone is going to make the background image huuuuuuuuuge because it’s scaling it to fit the height of the page content, not the screen size. I initially solved that with background-size: 100%;, since we’re now allowing the background to repeat. As you’ll see, however, that led to problems on Android, so I ended up scrapping it.

Android Problems

I opened the page in Android, and, although the background image was displaying as I expected in terms of size and attachment, it looked… awful. The original source image I am working with is a generous 2400 x 1857 pixels, enough to look reasonably sharp on most displays, even at high resolution. And it looks great on my Mac, great on my iPhone. But on the Android phone it was splotchy and low-res looking… like it had been reduced to 200 pixels and then upscaled (which is maybe what Android is doing, somehow… and here is where I’m wondering if the image being a JPEG is a factor, but that’s just a stab in the dark).

I tried a number of possible solutions, the most obvious being to set exact pixel dimensions for the image. I tried 1200 x 929, basically a “x2” size for high-res devices. Still looked like crap. I even tried setting it to 2400 x 1857, the actual dimensions of the image, and it looked like crap… and I don’t mean pixel-doubled, which is what it actually should be; I mean the same splotchy weirdness I had been seeing at other sizes.

Yet another quick side note: Here I am not placing this inside a media query. We don’t want to only fix this issue on phone screens. Granted, the iOS solution above needs to work on iPads, too… something I haven’t really solved here. I’m workin’ on it!

This change for Android worked perfectly! By this point I had, temporarily at least, removed the iOS workarounds I mentioned above, so on Android the background image was not only perfectly scaled to the browser window, looking sharp and clean, but it was even fixed-position, just like on desktop!

But… the image was back to being huuuuuuuuuge on iOS. Apparently this html trick for Android does absolutely nothing on iOS, so you’re left trying to find another solution that won’t simultaneously break Android.

An uneasy compromise

It’s not perfect, but I found that if I put both of these tricks together, everything works… the only thing we lose is the fixed-position treatment that Android allows but iOS does not. But the background looks great on both platforms and most importantly, behaves consistently on both.

As noted above, this doesn’t really address iPads. A simple solution would be to change the media query to @media screen and (max-width: 1024px), but a) that doesn’t account for the larger iPad Pro and b) it also means a desktop display will lose the proper background effect if the window is smaller than that size. I don’t really have a solution; an adaptive treatment using either server-side or JavaScript-based browser detection would be a consideration, but I don’t really like resorting to that sort of thing for something as basic as this.

It doesn’t help that I recently gave my iPad to my daughter so I don’t currently have a tablet of any kind for testing. That’s about to change as I have a newly ordered Kindle Fire arriving today, but of course that’s not going to give me the answer for an iPad. I can try Responsive Design Mode in desktop Safari, but that’s not always a perfect representation of the quirks of an actual mobile device.

Still… this combined solution for phones is an improvement over the default behavior in both cases.

So, a few weeks back, just 4 days before the iPhone 6 announcement to be specific, I wrote here that I wanted an iPhone 5c. I had been coveting the funky colors and unashamed plastic of them since they’d been announced, and I’d seen enough leaked photos and specs for the iPhone 6 that I already knew, if it lived up to the rumors, that I didn’t really want one.

The day after I wrote that blog post, I went for it. We went to the Apple Store and bought no fewer than three iPhone 5c’s, in fact — two 32 GB units and one 16 GB unit for the boy, who’s now in middle school and needs a way to communicate with us given his newfound independence — and switched from Verizon to T-Mobile in the process.

The rationale: regardless of what they did keep, I knew (or at least reasonably assumed) Apple would be discontinuing the 32 GB 5c once the 6 was announced, and I also knew that 32 GB was the “sweet spot” for my iPhone storage capacity needs. My faltering iPhone 5 had 64 GB of storage, and I had never used more than about 35 GB of that… and even then only by unnecessarily carrying around a half dozen full-length, HD movies on the device.

So it was that on the weekend before the iPhone 6 announcement, I became the proud owner of a gaudy, banana-yellow iPhone 5c. And it was good.

T-Mobile, so far, has been great. The guys at the T-Mobile store where I had to go the next day to activate my phone were fast and knew what they were doing, and T-Mobile’s service has been outstanding, with voice call clarity and LTE reliability I could never even have imagined possible with Verizon, at a little over half the cost.

But my joy didn’t last long. Not because the iPhone 6 surprised me — it didn’t. At all. But because less than 24 hours after I took my iPhone 5c out of the box, it fell out of my pocket as I got out of the car in our garage, and suffered a permanent ding in the plastic on the lower right corner. Fortunately it was very, very small. But it was big enough to consume a significant portion of my attention for the next two weeks. I touched it constantly. I stared closely at it, willing it to disappear.

It did not disappear.

On the night we bought the iPhones, I rationalized the obviously ludicrous purchase by noting Apple’s 14-day return policy. That gave me until the day after the iPhone 6 would go on sale to change my mind.

As it happens, a coworker had preordered the iPhone 6, and it arrived at the studio on Friday. I took a look at it. I held it. I even put it in my pocket. It was not bad… definitely not as obnoxiously big as I had expected. But I still didn’t want it. I would live with my iPhone 5c, scratch and all, for a year at least, until the next round of updates.

But then, the next morning, 14 days after my purchase, and therefore the last day I could return the 5c to the Apple Store, I was idly browsing Apple’s website.

The first thing I noticed was that the 5c, now the lowest-end iPhone, is now only available in an 8 GB size. I had assumed they’d keep the 16 GB around. 8 GB is just stupid now. But whatever. I had my 32 GB unit. I was happy.

Of course I was aware that the 5s had been bumped down to the mid-range level previously occupied by the 5c. Which meant that if I’d just waited a few days, I could’ve gotten a 5s for the price of a 5c. I didn’t really care. I knew it was faster, had a slightly better camera, and had TouchID, which I didn’t think I wanted. I was fine with my banana-colored 5c.

Until I looked at the price. The 32 GB 5s was now $50 cheaper than what I had paid for the two 32 GB 5c’s we had bought 14 days earlier. That meant we could take them back, upgrade to 5s’s, and get $100 back! Hell yes.

Not only that, I could get rid of the ding in the plastic that had plagued my mind for two weeks.

So later that afternoon, we trekked back to the Apple Store, past all of the people queued up outside to get iPhone 6’s, and straight to a blue-shirted employee who was more than happy to work with us and never once even glanced in the direction of the ding. 15 minutes later, we had exchanged our 5c’s for 5s’s and had gotten a big credit back to our bank account.

I used part of my $50 refund to buy a bright yellow case for my “space gray” iPhone 5s.

Next Tuesday, Apple will be announcing the iPhone 6. Supposedly they’re also announcing an “iWatch” or whatever. The latter is still shrouded in mystery but it really seems like we already know everything there is to know about the iPhone 6.

And honestly… I’m not sure I want it. Thinner? Yes, that would be great. That’s always great. But it’s not like my iPhone 5 is “thick.” Bigger screen? I guess. I’m fine with the size of my iPhone 5 screen, and I don’t want a larger slab to carry around in my pocket. Faster processor? Who would say no to that? Although to be completely honest, my iPhone 5 seems perfectly snappy to me.

So, yeah… I’m pretty happy with my iPhone 5. In fact, there’s only one reason I’m even interested in getting a new phone at all when my contract runs out this month. About a year and a half ago, I dropped my iPhone 5 on asphalt, and dinged the corner right by the camera. Since then, the inside of the camera lens has gradually accumulated dust, to the point where my photos are noticeably blurry, washed-out, and occasionally infested with weird splotches.

Would I be happy replacing my iPhone 5 with another iPhone 5? Yes. I’d be perfectly happy with that. But they don’t sell the iPhone 5 anymore. Instead they sell the iPhone 5c, which is basically the exact same phone but in a cheaper-to-produce (and possibly more resistant to the kind of damage mine suffered) plastic casing. And it comes in bright colors.

I want one. I want the obnoxious yellow one. And I’ve wanted it almost since they came out. For me, the only thing the iPhone 5s had going for it over the 5c was the A7 processor. But, again, I haven’t had any problems with the performance of the 5’s A6 processor.

So, I am left with a strange quandary. I am sure any of my fellow Apple fans will think I am an idiot (or worse) for seriously considering buying an iPhone 5c (actually, two of them) right now, on the cusp of the big iPhone 6 announcement. But here I am.

Apple always has three iPhone models available: the latest-and-greatest (currently the 5s), the last-year’s-model (in this case the 5c, a modified 5), and the two-years-old-model (the 4s). I am wondering what Apple is going to do with their new low-end phone after next Tuesday. Right now it’s the aging 4s, which will be discontinued. That would generally mean it’s time for the 5c to drop into that spot. If I wait until then, I might be able to get a 5c for “free” (“subsidized” by the carrier)!

But… the lowest-end model has only ever been available in a 16 GB size. I’ve learned over the years with iOS devices that I can’t really get by with less than 32 GB of storage. Right now the iPhone 5c is available in 16 and 32 GB models. But after next Tuesday, assuming it becomes the low-end model, the 32 GB version might disappear.

And what of the mid-level model? Will the 5s be downgraded to colorful plastic and renamed the 5sc or some other strange appellation? Would I want that instead? (Yes, I probably would, especially since it would most likely still come in a 32 GB version.)

At the moment I am considering hedging my bets, and buying two 32 GB iPhone 5c’s right now. Yes. Buy them. Keep them in the package. And for the love of all that is good in the universe keep the receipt. Then, wait and see. If I actually want something that gets revealed on Tuesday, I could return the 5c’s. If not, I have them.

Ever since upgrading to iOS 6, I’ve had a problem. The glorious promise of iMessage with its seamless integration of SMS/MMS and Apple’s messaging services between iPad, iPhone and Mac has mostly worked, with one infuriating, deal-breaking exception.

Texts to my phone number go to my iPad and not to my iPhone.

Look, all of this integrated messaging is cool. Being able to have text messages show up not only on my phone but on my other devices is awesome. But they have to at least show up on my phone or the whole thing is a failure.

I’ve researched the problem and found some people with somewhat similar issues, lots of stuff involving jailbroken iPhones (which mine is not), etc. but no clear answers to my exact problem. Several people in forums suggested shutting off iMessage on the various devices, deleting accounts, full-blown factory restore, you name it. All of which were either things I tried and found didn’t work, or wasn’t willing to try due to the amount of time and tedious work involved.

So I began experimenting. There was one distinct problem I could see in settings. On both iOS devices and my Mac, the Messages app was showing both my phone number and email address. But in some cases one was grayed out. Infuriatingly, on my iPad and Mac, the phone number was grayed out and checked, and on the iPhone the phone number was grayed out and not checked. I could easily add or remove the connection of my email address to any of the devices, but my phone number was stubbornly locked into my iPad only. (Or, well, my iPad and my Mac… I guess. Honestly I hardly ever use Messages on my Mac so I haven’t really paid attention.)

I wish I could give a clear account of what came next, but I started tapping various buttons and clicking various boxes with such a fury that it all became a blur. What I do remember is that I clicked the checkbox next to my email on my Mac, which un-grayed the phone number. I was then able to uncheck the phone number, and the email now became grayed out.

So, if I understand correctly, the way iMessage settings work, at least one receiving phone number/email address must be checked at all times, so if only one is checked, it’s also grayed out so you can’t uncheck it. Then, if you check the other one, you may be able to uncheck the first.

That wasn’t working on my iPhone, however. Strangely though (at least as I recall from the aforementioned blur), when I repeated the process from my Mac on my iPad, then took a look at my phone, it was already switched to having the phone number checked and grayed out.

So then I began running some tests. This is where things get muddy, and since all of this just happened a few minutes ago, I still may not have a complete solution. I tried sending a text to my phone number from SLP’s iPhone. Never got it. Then I tried sending a text to my phone number from my iPad and it went to my phone within seconds. Cool. Then I tried sending a text to my email address from SLP’s iPhone, and it immediately showed up on all three of my devices.

Everything then is working as expected except that I did not get the text from SLP’s iPhone to my phone number at all, on any device. It’s hard to say what that’s all about. Are things working now? I don’t know.

Here’s another weird thing to throw into the mix. SLP and I share an iTunes Store account, but we have separate iCloud accounts. I also have a separate iCloud account apart from the iTunes Store account. The iTunes Store account uses my “real” email address, and I have a separate me.com email address I use on iCloud. So that’s all kind of a big mess, yes I know. Anyway, whenever I made these various changes to my configurations, the iOS devices would pop up alerts regarding the change. These alerts also appeared on SLP’s iPhone, even though her Messages settings don’t have any of my account info associated with them.

The bottom line here, for me, is that Apple really has not dealt with the reality of multiple users on the same device, multiple family members sharing an iTunes Store account but needing their own iCloud accounts, etc. They may be trying to deal with it all, but they’re trying to integrate too many things that had developed for too long as independent products. And they’re not having as much success at it as they think they are.

This post began as many others here do, as an attempt to share my solution to an Apple conundrum. Unfortunately in this case I just can’t quite make sense of what’s happening, and it seems to be one of those dark-clouds-on-the-horizon portents of more trouble to come with Apple’s tendency for its ambitions to exceed its capabilities in the realm of networked services.

I just want it to work. Isn’t that the Apple promise?

Follow up: Just after posting this I had our neighbor — who also has an iPhone but of course does not share our iTunes/iCloud accounts — send a text to my phone number, and I got it. So the problem seems mostly resolved. But let’s leave it at this: if you share your iTunes Store account with another family member and you both have iPhones, you might need to send your text to each other’s email addresses instead of phone numbers, if you’re running into the same problems I’ve been having.