A bunch of us developers of Mail plug-ins and accessories have gotten together for a sale. Through October 10, you can get the following products at a discount: EagleFiler, Herald, InfoClick, Letter Opener, Mail Anti Inline Plugin, Mail Perspectives, MailButler, MailHub, MailTags, SigPro, SpamSieve, and Tealeaves. This is not a bundle, just a selection of quality products available directly from their developers via a shared coupon code: MAILTITUDE.
As far as I can tell, new restrictions have been placed on sandboxed apps in 10.12 that prevent such apps from using a variety of LaunchServices functions (or their NSWorkspace abstractions) that would reveal the path on disk of a specific other application.
For example, if I have BBEdit installed in ~/Applications, a sandboxed MarsEdit cannot tell that it exists. This is even though MarsEdit has an entitlement to send Apple events to BBEdit, and it can open documents in BBEdit, and BBEdit may already be running. With previous OS versions, NSWorkspace would let MarsEdit look up BBEdit by its bundle identifier, even though MarsEdit might not have access to read the returned URL. On Sierra, unless BBEdit is in the global /Applications folder, or another that sandboxed apps can read, NSWorkspace returns nil (and no error) as if BBEdit didn’t exist. Apparently, returning the inaccessible but nonetheless useful URL is considered a bug.
This is a bit surprising because we know that Launch Services is not actually scanning for applications from within the sandboxed app. Rather, it’s returning cached data that was gathered by a process with greater privileges. However, it turns out that that process verifies the privileges in the context of the application. The application only receives URLs that it can read.
My takeaways from this long Twitter conversation are:
Lastly, since this API change was not documented, I was thinking about how a developer might have detected it, other than through a bug report such as mine to Jalkut. The natural answer is unit tests. I have a lot of tests of basic OS behavior that can help detect changes and regressions. Unfortunately, as far as I know, Xcode can’t run unit tests inside the sandbox. So code that works as expected under test may not work as expected in an actual app.
The underlying problem, as noted above, is that downloading the app has a fixed cost. We’ve always set that cost to be the standard price of our app, leaving us no way to charge less. But what if we take a fresh look at this problem, and make our downloads free? You know, like every iPhone app in the Top Grossing List has already done? It’s not that they don’t sell anything—or they wouldn’t be on that list. They just don’t sell the original download. (Which we’ve never done on our own store either.)
With the original download free, we can implement any pricing options we want to offer customers through In-App Purchases. We can offer our standard unlocks of Standard and Pro, of course. But we can also offer a free 2-week trial which unlocks all of the features of Pro and Standard, letting you freely choose between them. We can offer a discounted upgrade to the new Standard. And we can offer free upgrades to the new versions to any customers who recently purchased the old app.
Marc Palmer proposed something like this in 2014. It’s not entirely clear to me whether Apple’s guidelines allowed it then, or even whether they do now. Nat Brown points to rule 11.9, which said that apps could not contain expiring content or services. It was removed when the guidelines were rewritten in June 2016. Ken Case says that “Apps can offer trials of optional content,” but are app features “optional content” in the same way as game levels? Rule 3.2.1 (iii) says (emphasis added):
Disabling access to specific approved rental content (e.g. films, television programs, music, books) after the rental period has expired; all other items and services may not expire.
Omni is not offering subscriptions, which explicitly can have trials. Perhaps it’s OK for the tier-0 IAP to expire because it’s free.
Either way, it’s key that OmniGraffle will perpetually work as a free viewer-only app if you don’t purchase any IAPs. Otherwise, if it didn’t do anything useful, Apple would not allow it in the store. This is a great fit for Omni, because they want everyone to be able to open their file format, anyway. However, this approach does not scale to other types of apps where there is no natural subset that can be made free.
Assuming Apple allows this, it sounds like a rather convoluted way to get to a pretty good place, although it’s also an admission that Apple is unlikely to make demos or upgrades built-in features of the App Store. Instead, developers will write a bunch of notoriously difficult code to approximate those features, and Apple will have less ability to ensure that it all works properly and consistently for customers.
Want to showcase an animation or an application feature? Instead of a static screenshot with paragraphs of text, a 3 second GIF works equally well and also draws more attention.
[…]
The following sample images were created using different quantization techniques. They illustrate the quality impact of the used algorithm on the final image.
[…]
The Image Descriptor section can be used to define a sub-image which does not provide pixel data for a full frame. Instead it contains coordinates and pixel data for a subsection of the full image.
By using frame differences and sub-images with a proper disposal mode, redundant image data can be avoided. Depending on the nature of the input video, this can greatly reduce the file size of the final GIF.
In the first high-profile iMessage App Store rejection we’ve seen, the developer of the Phoneys sticker pack says Apple has reached out with bad news: the company will pull the app in a week if it is not significantly changed. Phoneys (currently) features stickers that look like iMessage bubbles, effectively allowing users to replace messages from their friends with some funny alternative text.
The app hit #1 Top Paid in the iMessage App Store. Despite getting approved initially, Apple says that the store does not accept “prank apps” and the current form of the stickers violate Apple trademarks …
Bill was nice, but to the point. Apple’s lawyers weren’t happy that Phoneys got through the review process. The stickers couldn’t be blue or green, they couldn’t use San Francisco as the typeface, and the app could no longer be marketed as a “prank” app, because Apple doesn’t approve prank apps (even though I myself had never used the word “prank” when marketing Phoneys, others did, and I certainly understood where he was coming from). They were not going to pull the app, Bill made sure to emphasize. They’d give me a week, until next Thursday, to fundamentally change it so that the bubbles looked nothing like iMessage bubbles, instead looking something closer to “comic book cartoon bubbles”.
Update (2016-10-07): Adam Howell:
But, even though Phoneys is as dead as all those predictions that 2016 would be “the year of the bot”, the iMessage App Store is alive and thriving. And at not even 4 weeks old there’s a lot we still don’t know about it. So, I thought it’d be useful to publicly go into Phoneys’ numbers and see what they can teach us about the current state of the iMessage App Store.
