17 Jan 2016
I’ve not been able to release the changes to Count The Days Left mentioned in
my last post because of a very frustrating review from Apple’s App Store reviewers.
Review feedback
After waiting over a week for the new version to be reviewed, I received notification that it had been rejected. I assumed
this was because of the Xcode bug I documented in the last post,
but it was actually the following:
8.3 - Apps that appear confusingly similar to an existing Apple product, interface, or advertising theme will be rejected
8.3 Details: Your Apple Watch app contains features that mimic native iOS interfaces or behaviors.
Specifically, the Complication used for your Apple Watch app mimics that of the native ‘Battery’ Complication design and interface.
Next Steps:
Please revise these features to make them distinctly different from the iOS behaviors and interfaces to avoid causing user confusion.
Illogical
Now although the reasons given for the rejection are factually correct, they really don’t make any sense.
Here’s a screenshot from my watch, with the battery complication in the center and the Count The Days Left on the right:
However there is a very good reason it looks the same - it’s using the CLKComplicationTemplateCircularSmallRingText template
that is one of the few - and pretty restricted - template options available to a developer.
Almost certainly the battery level complication is using the same template, which makes a lot of sense. If you have a “progress” number you want to
show - which both the battery and my app do - this is the logical template to use.
Obviously if using this template in your app isn’t going to make it through an app store review, it doesn’t make any sense to allow
it in the complications SDK.
However the real answer is that using this complication shouldn’t be rejected by the reviewers. I’m obviously not trying to
pretend my app is a battery level complication, and when the user is selecting their complication which one is which (as you can see below):
It’s this level of over restriction of their platform that can make it very, very frustrating developing for Apple’s platforms.
I’m not advocating a free for all on allowed apps, and their needs to be quality control to not allow apps which abuse user’s data or the like.
However even the intent behind this rule doesn’t make any sense. The fact that my app’s complication looks like another one doesn’t harm
the user in any way at all, and if they want to use both at the same time then why shouldn’t they?
Inconsistent
If you’ve been following along as I’ve developed this app, you’ll have spotted the other flaw in Apple’s system.
The complication design hasn’t changed at all since the previous version which was deemed acceptable in previous reviews!
What to do next
I obviously appealed against the review to the App Store, giving the arguments I made above but it still got rejected.
I’m not sure how best to move forward now. I guess my options are:
- Resubmit the app again and hope this time I get a more favourable reviewer
- Change the complication so it looks differently, which will actually make the app less useful to its users
- Remove the complication from the app
- Give up, and just keep the improvements in the latest version for myself
Option 1 would be best, although it means waiting another week for a review with an unknown chance of success (probably low because I’ve already appealed)
Option 2 is what I may be forced to do, although it really pains me to make my app worse just to work around Apple’s incompetence
Option 3 would clearly make the app worse, and I know it’s a key feature for more than one user (including myself!)
Option 4 is where we are right now, and is where we’ll be until I find the energy to do something else :(
As you can probably tell, I’m not very happy on where this has ended up.
Links
30 Dec 2015
I’ve been making some minor updates to Count The Days Left
- Added an optional badge icon so you can see how many days are left without even opening the app
- Made the app universal so it works better on the iPad, improved the layout so it works in both in portrait and landscape modes, and can be used in Split View
Neither of these improvements are particularly interesting, but what I thought I’d write about was a very irritating bug
in either the App Store or Xcode 7.2 (or some combination of the two).
As you can imagine none of the changes are particularly massive, but uploading an archive to iTunes Connect gave some strange errors:
- WatchKit 1.0 - Your previous version used an extension for Apple Watch but your current version doesn’t. Users who haven’t updated their Apple Watch to watchOS 2 or later may lose access to their Apple Watch extension.
- Invalid Icon Name - The watch application ‘daysleft.app/Watch/daysleft WatchKit App.app’ contains an invalid icon file name ‘daysleft.app/Watch/daysleft WatchKit App.app/WatchAppIcon44x44@2x.png’. Make sure that icon file names follow the pattern “*@x.png" and they match the required dimensions. Please visit developer.apple.com/watchkit for more information.
In particular the 2nd error is strange, as I’ve just used the standard Xcode Images.xcassets template to set the images. There
is a 44x44@2x image required which I’ve definitely set to an 88 pixel square image, but it looks like there is a bug setting this
in the archive generation.
I’m definitely not the only person seeing this issues, as there is at least one existing Radar bug
been opened on the same topic. I also opened a Radar (23871724) - it seems opening duplicates is the best way of making sure Apple
know it’s a common problem - which is now closed as a duplicate of yet another one (23859182) - so hopefully this is being
addressed by Apple.
My guess is that this became a problem after I upgraded to Xcode 7.2, but I don’t have the energy to revert back to 7.1 to confirm.
I’m not sure if this will prevent the new version being released, so I’ve submitted it and all being well it’ll be available shortly.
05 Dec 2015
Everytime I manually had to create some thumbnails for josiemccoy.co.uk, or a whole
set of icons for an iOS app, I thought “next time I’ll write a script to automate this”.
Finally I got around to writing the script, which only took a few minutes which should save me, er, a few minutes each year.
Once I found the excellent JIMP package - a pure JavaScript image manipulation library -
it was easy to write a couple of scripts to do exactly what I wanted.
The script to generate all the image sizes required for an iOS app is available on GitHub if
you want to try it out yourself.
01 Dec 2015
After a pretty long development “sprint”, Daily Optimiser 3.0 has finally
hit the App Store.
Apart from lots of under the cover changes and UI improvements, the big news
is that the app - previously iPad only - is now available for the iPhone.
The reason it took us so long to release an iPhone version is we always assumed one of the
key features of the app is the ability to see both your task list and meetings in one view.
However after a few UX experiments it turns out - not for the first time - I was completely wrong!
Having a quick way of switching between the 2 lists is very useful, and the visible timeline
pulls together the two views in “task mode” nicely.
One thing I didn’t solve in this version is a reliable way to sync which reminders are “most important tasks”
in the cloud. I tried using Apple’s CloudKit, but this proved wholly unreliable in the way I was using it.
Unfortunately I had to pull the sync feature from this release, but will almost certainly revisit this topic
in later releases.
We’re also trying the “patron model” of funding, where users get all features for free, but if they feel so inclined
they can make a one off in-app purchase to support us. In other words, shareware :)
Be interesting how this pans out, whether the
(hopefully bigger installed base we’ll get for a free app make up for lost revenue).
I’ve got another idea for an interesting app, and I’m very much looking forward to tackling some new problems for a while.
25 Nov 2015
We found an “interesting” issue at work yesterday regarding IE, cookies and domain
names that I thought might be useful to share.
At FindMyPast - where I’m currently contracting - we heavily
use GitHub Flow which involves multiple development branches
being worked on at once.
By convention we use underscores in our branch names e.g. “dev_feature_branch”, and
have recently automated hosting of feature branches for test purposes. For example
for the above branch we’ll setup a host for dev_feature_branch.findmypast.com
For a feature I was working on, everything worked great on Chrome and Firefox, but for
some reason we couldn’t login properly using IE.
After much head-scratching, we fired up Fiddler which gave us the
answer.
!! WARNING !!: Server hostname contains an underscore and this response sets a cookie.
Internet Explorer does not permit cookies to be set on hostnames containing underscores.
See http://support.microsoft.com/kb/316112
The obvious solution is not to use underscores in the domain name used for the virtual host,
either by convention of stripping them out when setting everything up.
Hopefully if you see a similar issue, this may help you debug it quicker than we did!
