Tag Archives: ios

Apple Watch Series 4


This was going to be my first thoughts on the new Apple Watch, posted about a day after I unboxed it. But then life got in the way and I’ve now been using it for a week. What I’d planned to be a little more than a “hot take” is now probably a little closer to an actual review!

From the picture above you can see what I was using before. It’s not an Apple Watch, it’s not a competing smart watch. It doesn’t even have a battery. (To be clear, my new watch isn’t a replacement. I still plan to wear the Marloe.)

I’ll be honest: until recently I wasn’t very interested in the Apple Watch. It was too big, didn’t look nice enough, was another thing to recharge every night and none of the things it did were compelling enough to overcome those annoyances.

Here’s the thing. The Series 4 is still too big — about twice as thick as the Marloe — and doesn’t look as good as a traditional watch. But I’ve been on a health kick for the last year, so partly I bought it as a new gadget, a reward for keeping going for twelve months, and partly, because of that, the health features became compelling enough.

As you’d expect for Apple, the hardware looks great and is well presented. The finish is beautiful, the controls click and rotate in a satisfying way. I found it odd that it came without the strap attached but I was able to get it up and running pretty quickly.

I’ve read about the Watch before but I’ve never got beyond playing around with one in a store. It surprised me how complicated it is. By which don’t mean it’s hard to use, rather that there are a lot of choices to make. Choices that you probably won’t know the answer to.

The new Infographic watch faces sound great, but what am I supposed to do with eight complications? Not having used the Watch before, I don’t know the best way of accessing apps versus having the information available instantly on the watch face. Should I use the app swarm? The most recently used list? Complications? Notifications? Then you find that some complications only appear in some locations. How am I supposed to know this stuff? It’s confusing. I’m sure I’ll figure this stuff out but I feel information overload just as I’m trying to play with my new toy. (Having started writing a Watch app I think I understand it better, but should I have to?)

I guess I was expecting an iPhone OS 1.0-type experience — just the bare minimum — but I suppose that’s an unfair comparison and an unfair expectation. We’re now at watchOS 5, so it’s had time to evolve. And in hardware terms the Watch is way faster than than the first few iPhones. (It is incredible that you can get a dual core 64-bit CPU on your wrist!)

Having waited until now to get a Watch, I’ve also seen features that I was concerned about. The main one: the not-always-on screen. Would I forever be wiggling my wrist to see the time?

No, is the short answer. It’s not 100% successful turning the screen on at the right times but it’s pretty close. The problems I’ve had have been more along the lines of the screen not staying switched on for quite long enough. Maybe I was too slow to read a notification, or I was showing my wife something neat, but I do occasionally find myself wiggle my wrist around just as I feared. Fortunately the times it happen lead me to think that, as I use the watch more, these occasions will happen less and less. I could be wrong, but I think this will work out fine.

Another example of complexity: if I want to go running, what app do I start? Strava is the obvious one. That’s what I use on my phone. But what about the Workouts app? Do I need that instead? As well? One of the features that attracted my to the S4 was the ability to see my pace for the last kilometre… but how do I get that while recording my GPS trail? Clearly this isn’t an insurmountable problem, but it’s one without an obvious solution. Some experimentation will be needed.

However, putting the niggles and unexpected complexity aside, how has it been? My experience in this first week has been great. Being able to quickly glance at notifications without pulling out my phone has been very handy. Walking around a strange city with it tapping my wrist with the directions is way more convenient, as are the notifications telling me which gate my flight boards. And being able to record a run without clutching my phone or have it strapped to my arm is surprisingly liberating.

I’ve heard people say that Watch apps are not great. Maybe that’s true on average but I’ve been impressed with Strava and, especially, Overcast.

All these things are slight reductions in friction or increases in convenience and are not necessarily compelling alone but when you add it all up it’s impressive. On paper, I thought the features were nice but not quite worth the asking price. I would still say it’s a luxury rather than a must have but the utility is certainly there.

iOS 12

As I’ve done for the past few years, here are a few thoughts on the new version of iOS that will be heading to your phone in a few days. Usual caveats: my usage patterns are probably different to yours, I have a 6s and iPad mini, not whatever weird and wonderful hardware you have. I’ve been using the beta on my iPad since early August and on my iPhone since late August.

The good

  • Stable. I’ve had a couple of minor glitches but, honestly, there have been worse release versions. (They have been fixing new APIs and suchlike so I’m not saying they should have released earlier. But I am saying that the GM version should be pretty solid.)
  • Performance. As advertised, it works well on my far-from-new devices, probably better than iOS 11. I didn’t buy into the whole battery-gate scandal but if this is the result I’m happy with it.
  • Siri suggestions. I’ve not seen the full benefits yet, since I’ve not finished writing my own and haven’t been running anyone else’s beta software. But even just with Apple’s suggestions it’s nice. I go to the gym and it suggests my “gym” notes document. I think this is going to be big when more apps support it.
  • Do not disturb. I already used it a lot and now it’s better. DND until the current meeting and DND until I leave the current location are both super useful.

The bad

  • Nothing. Really. Sure, there are things that I would change or do differently, but there’s nothing that I would really look at and say “That’s worse than iOS 11.” If you’re okay with iOS 11 there’s no good reason not to update.

The ugly

  • What’s with the time and battery indicator being jammed in the very top left and right of the iPad screen? What a waste of space.

Final words

You’ll note that “Screentime,” Apple’s answer to the accusations that people are spending too much time on their devices, is not on the list. I don’t have anything bad to say about it, but I didn’t find it very useful. I have my smartphone addiction under control. I could stop any time I want to…

iOS 11

As I’ve done for the last few years, here are a few quick thoughts about today’s new iOS release, version 11.

I’ve been using the iPad version since the beginning of August and the iPhone version for only a couple of week but I think I have reasonable picture of what you’re going to see. 

Good

  • Multi-app support on the iPad. Wow! It’s quite different. You might need to give it a while before you get used to it. I also found that I needed to rearrange my dock so that apps I use to multitask are quickly available
  • “Swipe up on the iPad keyboard to get symbol characters.” Such a time saver
  • The voice synthesis of Siri is way better. But I agree with Gruber, if I could have dedicated engineering resources to Siri that wouldn’t have been where I would put them
  • iCloud sync for Photos. No more training each device to receognise each person!
  • Lots of nice, minor changes. The “Now playing” lock screen widget, the “play” button at the top of playlists/albums in the music app
  • Control Center is improved (but see first item in the “ugly” section below)

Bad

  • I’m guessing this has something to do with the iPhone X, but the one 3D Touch gesture I used all the time was the hard-press on the left side of the screen to trigger the app switcher. That’s gone in iOS 11. This is going to take a lot of getting used to
  • It won’t work on older devices. I get the “why” but it always sucks when they get left behind

Ugly

  • Why did the WiFi button is Control Center change to be “disconnect” rather than “switch off”?!
  • Not sure about some of the animations, especially on iPhone. 

Moving an app from Paid to Free

I’ve seen quite a few people saying that it isn’t possible to move an iOS app from paid to being free with an in-app purchase to unlock the full functionality. Fortunately they’re wrong.

“Traditionally” I would have had to remove version one from sale and offer a completely new app, which would have meant that existing users would have to pay again to get the same functionality. Or I’d have to support two apps. Or I’d keep the same app in the store and all existing users would get downgraded to the free version. None of these solutions seemed fair to existing users.

What I wanted was for people who had bought version one to get the full, unlocked version and for new users to be promoted for the paid upgrade.

Since iOS 7 came out in 2013 that it entirely possible. I’ll explain how it’s done here. This isn’t just some theoretical “I’ve seen the documentation” claim – I’ve done it with one of my own apps, Rootn Tootn.

The really short answer: take a look at the session 308 video from WWDC 2013. That’s the only information from Apple that explains how to do it. They have documented the API calls that are required but the actual process is left as an exercise for the interested student. And there are quite a few steps if you want to do it properly.

Firstly you need to get the app receipt. Before iOS 7 this only made sense for IAP but now they are available for all purchases and come in the same format as receipts from the Mac App Store.

Receipts have a number of useful features. In the past they have been used to validate purchase, and they can still be used for this. What’s interesting with the new receipts is that they include both the original purchase and the version number of that original purchase. This means that we can decide whether a user gets the paid functionally by looking for either an in app purchase or a purchase date before a particular time or, more likely, before a particular version.

When you download an app you should get a receipt automatically but you can also use the SKReceiptRefreshRequest class to force one to be generated. (This is also useful during development where, obviously, there is no receipt.)

Once the refresh has completed, you use [NSBundle appStoreReceiptURL:] to access the receipt.

Once you have the receipt the bad news starts.

It’s not in a user friendly format. And Apple do not provide any APIs to read it. Check out Apple’s documentation:

The outermost portion (labeled Receipt in the figure) is a PKCS #7 container, as defined by RFC 2315, with its payload encoded using ASN.1 (Abstract Syntax Notation One), as defined by ITU-T X.690. The payload is composed of a set of receipt attributes. Each receipt attribute contains a type, a version, and a value.

If security is important to you, you should probably write your own code to do this. ASN.1 is a standard format and it’s not that hard.

There are apps that generate the validation code, such as Tighten Pro and Receigen. I can’t vouch for either of them but the reviews seems positive.

There are also Open Source projects that do the same thing. I’ve used RMStore; there’s also VerifyStoreReceiptiOS. The main disadvantage of these is that, as standard, open code it makes it easier for crackers to reverse engineer how you remember that a purchase has been made.

And there you have it. It is possible. It’s just a lot harder than you might imagine. Remember this when someone tells you that it can’t be done.

ShareEverywhere

ShareEverwhere main screen
ShareEverwhere main screen

I was so busy when it came out that I never quite got around to blogging about it here: I have a new app out! It’s called ShareEverywhere. It is built exclusively for iOS 8 and uses the new, built-in “share” functionality, allowing you to share to a good number of services from any app that uses the standard share button.

When I first wrote it, I wasn’t sure how many, if any, developers would build share widgets into their apps. Now that we know the answer is “a lot of them,” I still use ShareEverywhere because it beats having a dozen widgets hiding in your action menu. And there are still services, like Pinboard.in, that don’t have their own native apps.

It’s available now in the App Store for your iPhone or iPad. It costs £1.49, $1.99, €1.79 or your local equivalent.

Swift Types

If you look at the Swift Language guide, you get the distinct impression that the type system is sleek and modern. However the more you dig into it the more eccentricities you find.

The one I’m going to look at today makes sense only if you look at the problem domain from a slightly skewed perspective. I’ve been trying to think whether this is a sensible, pragmatic way of designing a language or a mistake. Judge for yourself.

So, the feature. Let’s define a dictionary:

var test1 = [ "Foo" : "Bar" ]

Check the type and we find that it’s of type Dictionary<String,String>. The generics and type inference are doing exactly what you’d image.

test1["Test"] = "Works"

So basically it’s all good.

So, what type is this expression?

var test2 = [:]

And why does this not work?

test2["Test"] = "Doesn't work"

Let’s take a step back. What’s the problem? Well, [:] is an empty dictionary but give us no clue what the type is. Remember, Swift dictionaries and arrays use generics, so the compiler only allows objects of a particular type to be added.

A good guess for the type would be Dictionary<AnyObject,AnyObject>. But a little fishing around tells you that’s not the case because AnyObject is neither “Hashable” or “Equatable” and keys need to be both.

The answer? test2 is an NSDictionary. That is, in this one circumstance, Swift extends outside its native dictionary type and decides to use a class found in Foundation.

Once you know that, it is clear that the second line should be:

test2.setValue("Does work now", forKey:"Test")

Maybe if you’re familiar with the guts of both Objective C and Swift this behaviour makes sense, but a language built-in returning a completely different type just because it can’t figure out the type feels broken to me.

In the end I think I’ve convinced myself that, while it might be convenient to allow this syntax, it’s a bad idea to saddle the language with these semantics so early on. In a few years when no one uses Objective C or when Swift is no longer fully tied to Cocoa, will this make sense?

I would prefer to see it being a compiler error with the correct approach being explicit with the type:

var test2:Dictionary<String,String> = [:]

Thoughts?