Opinions

iPhone SE, by Apple, Inc.

Before I tell you why I won’t be buying one, let me say this: I love the iPhone SE. I love its form factor, I love its power.
As a matter of fact, I’m still using – and loving – my iPhone 5s and I think, for me, the 4’’ screen is just perfect.

Why I Won’t Buy the iPhone SE

Personally, I want to keep to the 4’’ form factor, but I can’t. As a user, I probably could do without 3D Touch, but since I want to develop for it, I need some way to test it. While the simulator with Magic Trackpad (Force Touch) support is nice for initial development, I’ll have to test on a real device sooner or later (and better sooner rather than later).

So as a user, I’d probably purchase the iPhone SE, but as a developer, I can’t do it, so I’ll have to wait for the iPhone 7.

But let’s get on to the actual point of this post.

IPhone 6s Taptic Engine 3D Touch

Why The iPhone SE Should Have 3D Touch

It’s clear to me why Apple isn’t including it – it gives the iPhone 6s and Plus (and future “mainstream” iPhones) a USP and makes it more attractive for surely lots of users, while allowing to offer a slightly cheaper iPhone for those that don’t have as deep a pocket.
Still, I think it’s a mistake not including 3D Touch in the recently announced iPhone SE. Here’s why.

It “Cheapens” the Technology

To play a Live Photo, normally you’d Force Press. On the iPhone SE, you long-press to play Live Photos. The question then becomes, what do I really need 3D Touch for?
Live Photos kind of were presented together with 3D Touch (Live Photos on the Lock Screen), but a long press does this just as well, so, yeah, whatever.

IPhone 6s 3D Touch Quick Action

It remains useful for Peek & Pop and Quick Actions, of course. So not having that on the iPhone SE is bad for all involved:
– The User, because they can not use these functions on an iPhone SE
– The developer, because their apps could be perceived as less functional because of it
– Apple, because of those two reasons

It May Stifle Adoption and Innovation by Developers

Quick Actions as well as Peek and Pop are pretty easy to implement with the APIs Apple provides for it, but anything that goes beyond it does take a certain amount of work and effort.
With only the “premium” iPhones having 3D Touch, developers (especially indies, who have less resources) will think twice before taking what might turn out to be a couple of weeks to implement a unique or innovative use of 3D Touch, seeing as they might not reach the entire market with it and having to develop and maintain different code-paths for different devices.

TL;DR

The iPhone SE will probably be sold for years to come and seeing as it’s a lower-priced phone, its customers are (in my way of thinking) less likely to upgrade, say, every year, which means 3D Touch will not be available “everywhere”™ for too long a time to come for the technology to go “mainstream” among developers to do something beyond Peek & Pop or Quick Actions.

Read more

As you might know, I’m currently in the process of getting flickery into the Mac App Store. I know, I’m a little late to the game. I originally had planned to have flickery in the Mac App Store when it first launched, however, time was not on my side.

Anyways, flickery has been rejected from the Mac App Store. For two reasons.

Reason for Rejection #1: Private API.

I’m using a great framework called BWToolkit in flickery. It’s a UI framework with HUD-style buttons, scrollbars, etc – you get the idea.

Apparently, it uses private APIs for its NSTokenField subclass (which I was not aware of at the time of submission and – thank god – am not currently using in flickery).

I get why usage of private APIs is discouraged (or simply, not allowed) – they might not be there in a future release of the OS, there might be something wrong with it in certain cases, etc and I’m happy to comply with Apple on that matter. However, this next point kind of bugs me.

Reason for Rejection #2: Installing of Plug-Ins for iPhoto and Aperture.

The Developer Agreement states:

 

3.3.2 An Application may install or run additional interpreted or executable code (e.g., plug-ins and extensions) for use in conjunction with the Application as long as such code:

– does not change the Application’s submitted binary or would not otherwise be considered an Update (as determined in Apple’s sole discretion); and

– does not change the primary purpose of the Application by providing features or functionality that are inconsistent with the intended and advertised purpose of the Application as submitted to the Mac App Store.

 

I guess that is applicable for video conversion-applications which need to download some kind of codecs or frameworks that can not, for legal reasons, ship those codecs with it. Some of these applications do not work without those codecs and demand you download them, otherwise you have to quit. I do understand why Apple does not want that. It’s inconvenient to the user, it’s tedious and it just plain sucks, in my opinion.

However, if you ship a photo sharing application it only makes sense to include plugins for iPhoto and/or Aperture, for example, so users can access their photos right from the source. They are not installed automatically, but at the user’s request (if they were installed automatically, that would be another story).

It does not change the submitted binary and it certainly does not change the primary purpose of the application (by providing features or functionality that are inconsistent with the intended and advertised purpose of the Application as submitted to the Mac App Store). One of the primary purposes of the application is to get stuff on flickr. With a plugin for, say, iPhoto, it makes it very convenient for the user to do so.
The features and functionality are there anyway, uploading works both with plugins not installed or installed.

If this is a violation of the rule, why not just disallow plug-ins altogether? What the flickery exporter plug-in for both iPhoto and Aperture does is the very definition of a plug-in, don’t you think?

A Solution?

It’s no solution, it’s more of a workaround which other applications currently use as well.

I re-submitted flickery with the plug-ins removed, albeit with a button to go to a webpage to download the plugins. flickery will install them for you if you drag them onto it (I hope they’ll allow that).

However, I don’t go down without making some sort of noise. I did write an eMail to the Mac App Store team regarding this, asking for a re-evaluation of this topic.
If they (however unlikely) do change their minds, I will be happy to re-add those plug-ins to flickery.

Fingers crossed.

[twitter-follow screen_name=’eternalstorms’ show_count=’yes’]

Read more

Dear reader, honored customer.

I’m sure you’ve noticed – the Mac App Store is upon us. Finally.

What a great idea, a great, comfortable way to purchase software (and to sell, for developers). I’m excited. I hope you are, too.

Now, you might have noticed that flickery, well, really none of my software, is on it, yet.

There is a good reason for it:
There’s this whole dilemma about not being able to transfer existing customers over to the Mac App Store. That is a big deal. And it’s confusing as well, because some apps show as “Installed” even though they were not purchased on the App Store. So people naturally assume they are able to update that version through the Mac App Store. That is, sadly, not the case.

Here’s what I’d like to do:
flickery is “close” to version 2.0. “Close” because it’s only close in version numbers (the current version is 1.9.2), not in execution/development.
I’m planning to go Mac App Store exclusive with flickery with version 2.0! 
Now there’s a caveat for existing customers. On my website, I currently promise that users who purchase flickery get a discount on version 2.0. With the Mac App Store, I can not keep that promise, because it doesn’t have an “upgrade” model.

So I’d like to put it in my customers hands:
Would you be offended if I moved to the Mac App Store exclusively and you and didn’t get that discount for version 2.0 of flickery? Please leave a message in the comments, mail me, tweet me or write me on facebook to let me know what you think. I will decide by majority of votes.

New software by me will be exclusive to the Mac App Store as well (new software as in the upcoming rewrite of GimmeSomeTune, ProjectX and ProjectiX.)

What’s the difference for the user?

  • Keep informed on updates
  • A centralized place for your software
  • Easy updating and installing
  • They have to have OS X 10.6.6 at least to run software
  • The security that they get quality software
  • A ton of other things I’m probably not thinking of right now

What’s the difference for the developer?

  • Having to maintain only one version of their software
  • This is a very big deal, because time is precious and better spent on new features / new software.
  • Centralized updates – yes, it’s also a plus for the developer
  • Higher visibility to the user

To summarize:
I’d like to go Mac App Store exclusive with all my software. Starting with flickery 2.0 when it is available (quite a couple of months off – and there surely will be other updates before that which will not appear on the Mac App Store but through the current updating mechanism). To do that, I’d have to break my promise to give the existing customers a discount on the upgrade.

Future software not yet released will appear on the Mac App Store exclusively, as well. That means that all my software will require Mac OS X Snow Leopard 10.6.6 at the least. So, please let me know what you think about that in the comments, by mail, twitter or facebook.

I hope I’ve covered about all of what’s important in this regard.

Thank you for your time,

Sincerely,
Matthias

[twitter-follow screen_name=’eternalstorms’ show_count=’yes’]

Read more