Ole Zorn quotes the App Store Review team:
Your app, Pythonista (528579881), has been removed from the App Store due to an unresolved issue.
He seemingly had no idea what this issue was, having recently removed some features from the app and had it approved again.
Several hours later:
Thank you for contacting the App Review Board. The app is now for sale on the App Store.
There was apparently no explanation or apology.
The App Store is nearly six years old. It is still hostile to developers. I see no evidence that Apple even recognizes that there’s a problem. Android is finally forcing Apple to respond with more screen sizes and extensibility, but the Google Play Store doesn’t seem to be applying much pressure.
Android App Store App Store Rejection Google Play Store iOS iOS App Pythonista
Michael Donald Buckley (via Ole Begemann):
Apple introduced Swift as “Objective-C without the C”, but in many ways, Swift is closer to “C++ without the C” (or Objective-C without the Smalltalk). Swift’s generics, for example, are closer to C++’s templates than to any feature of Objective-C. One of the more subtle ways that Swift resembles C++ is in how it calls methods. Unlike Objective-C, where methods are called using message passing, Swift uses a vtable for method dispatch, and when the compiler has enough information, inlines the function call directly. While this improves performance over message passing, it trades power and flexibility for performance gains that aren’t necessary for most apps.
In this article, I will present use cases which are currently impossible or difficult to implement without message passing.
[…]
Objective-C isn’t going away any time soon, but if Swift succeeds in becoming the dominant language for iOS and Mac development, Objective-C will go away. Eventually the cost of maintaining two languages and runtimes will cease to be worth it. Like Carbon before it, Objective-C will be deprecated, leaving Swift as the only supported language for app development on Apple platforms. In general, I am loathe to argue that my way is the one true way to do things, but since Swift will eventually be the one way to do things, and since now is the time when large changes will be easiest to introduce, I feel compelled to argue that Swift should forswear all but message passing.
[…]
On the Mac, swizzling is used to implement plug-in functionality, even for apps that don’t have a plug-in API. This adds features that are very important to power users. Many popular Photoshop and Xcode plug-ins use method swizzling. GPGMail, a plug-in for Mail.app which adds OpenPGP encryption to Mail.app, makes extensive use of method swizzling. This functionality is incredibly important to security-minded individuals, especially in the wake of the Snowden leaks. If Mail.app were rewritten in Swift, this would not be possible.
Drew Crawford:
Swift already does have a way to opt-in to message passing, it’s called the @objc flag (and performSelector:). It works fine, but it’s extra work to opt into it and use it. But, I don’t think that’s bad given that it disables so many useful optimizations.
What may be bad is that the name “@objc” is a dead giveaway that this is a feature with a deprecation date. So I think we need some other, reflectionish system going forward.
Michael Donald Buckley:
My argument is that Swift will be primarily used to write high-level apps. For these apps, message passing is almost never a bottleneck. Swift is not going to replace the optimized C and C++ code, especially for the really low-level stuff.
But even if Apple does decide to rewrite all the Core* frameworks et. al. with Swift, there’s still an argument that Swift should use message passing by default, and a way to opt in to vtable and direct dispatch for performance-critical code. For higher-level apps, message-passing is a lot less useful if it’s opt-in.
Marcel Weiher:
To me it looks like replacing ObjC and the frameworks (over time) and the style that puts everyone on an equal footing. So instead of having a language where anyone can build something like Core Data, you will have a language with built-in support for Core Data. Apple’s Core Data, that is, and you will like it. Just another tightening of the screws (App Store, App Store–only APIs despite promises).
Update (2014-07-05): Michael Donald Buckley (via Sash):
In the rare occsion that objc_msgSend is a bottleneck in an Objective-C app, there are techniques like IMP caching that can improve performance, and that’s really the kind of thing I’m advocating here. Give developers some way to opt in to vtables when there’s a real performance problem, but allow the greater flexibility of message sending by default. It’s possible to start with message passing and optimize when needed, but it’s not possible to start with vtable dispatch and use message sending when needed.
Message sending allows many problems to be solved with much less code. This increases programmer producivity and lowers maintenence costs. Since message sending is fast enough in most cases, the end user sees no difference between vtables and message sending, so Swift should use the solution that results in better programmer productivity.
Language Design Message Passing Objective-C Programming Swift Programming Language
Jim Dalrymple:
Apple introduced a new Photos app during its Worldwide Developers Conference that will become the new platform for the company. As part of the transition, Apple told me today that they will no longer be developing its professional photography application, Aperture.
[…]
Apple was very clear when I spoke with them this morning that development on other pro apps like Logic Pro and Final Cut Pro is continuing. Professionals in those app categories should not worry about their apps—they will continue as normal.
I would have thought that Final Cut Pro X was the warning to video professionals. Apple may care about a particular product category, but it seems to have little regard for files, AppleScript workflows, or plug-ins that professionals (or even prosumers) rely on.
Jason Snell:
The Photos app, previewed at the 2014 Worldwide Developers Conference, will become the company’s main photographic focus for both professionals and consumers. As it grows, Apple intends the single app to serve the needs of both consumers and professionals. (That will be an interesting challenge; it will be intriguing to see how Apple puts all of its photographic eggs in a single basket.)
The same will be true on the iOS side, where the mobile iPhoto app will disappear and the Photos app will become the focus of Apple’s photography-related app development when iOS 8 is released in the Fall.
It was not explicitly said, but it seems clear that this consolidation will come at the expense of the professional features.
Benjamin Mayo:
The new Photos app will include many of the advanced features contained within iPhoto and Aperture, but also offers the big advantage of syncing with iCloud Photo Library, which will sync every photo you take when iOS 8 and OS X Yosemite ship later this year.
One of the best parts of Aperture is its filing system and storage options. The focus of the Photos app is the cloud. I doubt local storage features will make the cut. I’m guessing that by “advanced features” Apple does not mean offline images and masters stored across multiple drives, but rather “some of the editing controls that are not in iPhoto.”
Matthew Panzarino:
Apple says that it will provide compatibility updates to Aperture that allow it to run on OS X Yosemite, but will not continue to develop it. Adobe says that it will ‘double down’ on Lightroom support and offer Apple users a way to migrate.
[…]
Article updated to clarify that there is no official workflow for migrating to Lightroom.
I tried Lightroom early on but much preferred the way Aperture was designed. I still really like Aperture, even with lack of updates. Part of the appeal of apps like Aperture is that your whole edit history is stored. Now that is likely lost, along with the GPS tracks that I imported. I don’t see how much can be migrated to Lightroom, which has a different engine for applying adjustments—and also a different data model in other respects.
Update (2014-06-27): Winston Hendrickson (via John Gruber):
Put simply we’re doubling down on our investments in Lightroom and the new Creative Cloud Photography plan and you can expect to see a rich roadmap of rapid innovation for desktop, web and device workflows in the coming weeks, months and years. We also continue to invest actively on the iOS and OSX platforms, and are committed to helping interested iPhoto and Aperture customers migrate to our rich solution across desktop, device and web workflows.
Jeffrey Tranberry:
We’re working on a way for iPhoto and Aperture customers to more easily migrate to Lightroom. As of right now, your best bet is to save any metadata to your files, then import the files directly from disk. (Note: Aperture develop settings aren’t compatible. If you want to preserve the look of your image edits, export rendered versions of your files from Aperture to import to Lightroom).
That’s what I was afraid of.
Update (2014-06-28): There are lots of comments at ApertureExpert and Ars Technica.
Jesper:
When the groundbreaking Lamborghini portable ash tray/coin receptacle ships next year, Lamborghini drivers will be able to migrate their existing pennies and/or cents. Lamborghini’s well-known track record in ad-hoc loose small-denomination currency storage and management is unparalleled and unrepentant.
Sam Machkovech:
When asked about what Aperture-like features users can expect from the new Photos app, an Apple representative mentioned plans for professional-grade features such as image search, editing, effects, and most notably, third-party extensibility.
Nick Heer:
I mean, the new Photos app is really impressive, but it’s not Aperture. It absolutely looks like a valid replacement for iPhoto, but not Aperture. I could switch to Lightroom, but I hate its editing workflow.
John Gordon:
Meanwhile, in the real world, the announcement that Aperture was dead, and that Apple was effectively abandoning professional photography, appeared via Jim Dalrymple’s blog. Aperture remained on sale in the App Store while muddled Apple clarifications showed up in various blogs. Some said saying there would be support through Yosemite, others hinted at helping Adobe with migration to Lightroom. As end-of-life announcements go it was a complete screw-up.
[…]
As of today none of my 20,000 or so non-destructive image edits will convert to Lightroom, much less album/image relationships, image/project, folder/image/project, folder/project comments, geo-tags and more.
[…]
The way Apple executed Aperture’s termination is a rich lesson in the consequences of data lock (a risk I understood when I signed up with iPhoto long years ago).
Clark Goble:
You’d think they’d have learned after the Final Cut Pro mess and the iWork mess how to make these announcements.
[…]
The issue isn’t Apple killing a dying product. Rather the issue fundamentally is why people should trust Apple with their data when they’ve pulled this three times in a row.
Update (2014-06-30): There are more comments from TidBITS readers.
Update (2014-07-06): Jeff Carlson:
Apple has a notorious history of clear-cutting old software to make room for new in this way. iMovie, for example, gained a brand new approach with iMovie ’08, but didn’t catch up to the previous version’s feature set for a couple of revisions. And many Final Cut Pro users are still hanging onto their editing systems three years after the introduction of Final Cut Pro X. The ones who did make the switch wisely completed projects in the old version and reserved Final Cut Pro X for use with new projects.
With photos, however, you can’t just disregard old photos and move forward with the new, unless you’re willing to make a clean break and risk that your old library may become inaccessible. Part of having a photo library is to be able to reach into it to find old images. Abandoning a mature application like Aperture, where users probably manage thousands or tens of thousands of images, is complicated.
[…]
Chances are, unless Apple has really spent all this time building a deep application while ignoring Aperture and iPhoto, Photos for OS X will fall down in one or more of those areas. (I’d love to be proved wrong.) But Apple’s pattern of re-engineering applications and releasing them with core — not comprehensive — functionality doesn’t make me optimistic.
John Gordon:
“Wow, we’re gonna have a lot of mad customers. But, hell, what are they gonna do? It’s easier to change gender than to move from Aperture to Lightroom — and Adobe ain’t gonna last much longer anyway. There’s no money in pro software, and they got nothing else.”
Robert Boyer:
Are pro needs really different from consumer needs in still photography? I’ll venture that they are not.
Update (2014-07-11): Jeff Carlson:
No matter what’s to come, you can start to take steps now to prepare for your transition—whether that means switching to Photos or migrating to another third-party photo application.
Adobe Lightroom Aperture Datacide Mac Mac App Photography Photos.app Sunset
Debug 40:
Debug is a casual, conversational interview show featuring the best developers in the business about the amazing apps they make and why and how they make them. In part 2 of the Nitin Ganatra trilogy, the former Director of iOS apps at Apple talks to Guy and Rene about working on Mail for OS X, and the early days of Purple, the experience project that would ultimately deliver the iPhone.
Previous reports had described a competition between P1 (the iPod-phone developed by Tony Fadell’s team) and P2 (the OS X–phone) as though Apple waited a long time to decide which way it wanted to go. Ganatra makes it sound as though P2 was always what Apple wanted to do, and P1 was only there so that Apple would have a stopgap product to ship if P2’s development took too long.
Apple Mail Contacts History iOS iPhone Mac Mac OS X 10.4 Tiger
