Marcel Weiher:
When we actually measured the performance of applications adopting CoreData at
Apple we invariably got a significant performance regression. Then
a lot of effort would be expended by all the teams involved in order to fix
the regression, optimization effort that hadn’t been expended on the original
application, usually making up some of the shortfall.
[…]
CoreData may well be the best implementation of an in-process-ORM simulating a client-server enterprise app there is, and there is good evidence that this is in fact true (certainly the people on it are top notch and some of the code is amazing). However, all that doesn’t help if that’s not what you need.
This is in response to Drew Crawford’s year-old post, which we’ve been discussing on Twitter. The post stated:
Well, I don’t think there is a real reason not to use Core Data for virtually any project of any size.
It hasn’t aged well given the realities of Core Data syncing.
My view is that Core Data is often the wrong choice but that, unless you know that you will only have a small amount of data, it makes sense as a default choice. Core Data is a generalized framework that’s relatively easy to use. I think it’s often good enough, though some smart people disagree.
For a specific problem domain, you can probably make a custom solution that’s much faster, but that effort may be better spent on other parts of the product. You do, however, need to watch out for what Crawford charitably calls “corner cases,” where Core Data’s performance is abysmal compared to SQLite’s (also a generalized tool). There are probably good reasons that Apple doesn’t use Core Data for applications like Mail and Aperture that deal with lots of data. (It’s interesting to take a look at the SQL that Mail uses.)
A trend I see, among both Apple and third-party applications, is using Core Data (or SQLite more generally) as a cache or cache-like layer. The “real” data is persisted in a more open format. The database is there to manage the working set and provide fast queries.
I currently use Core Data in two of my apps (and am adding it to a third) and have few complaints. However, I don’t always use Core Data objects as my model objects. Core Data’s threading model is unsuitable for EagleFiler, so it uses a sort of repository pattern with plain objects atop the database layer, which can be swapped out. And in some areas it doesn’t use Core Data at all. I see Core Data as a persistence tool, like FMDB, rather than as a complete solution.
Looking forward, Tony Arnold discusses where we are:
The problem is, everyone uses Core Data because there’s nothing better. It’s the best way to persist structured data on iOS and OS X, but it’s not actually much fun to implement and has many warts.
and what he thinks should be improved. To his list, I would add that indexed full text searching is sorely needed.
Aperture Apple Mail Cocoa Core Data EagleFiler FMDB iOS Mac Programming SQLite
Greg Pierce introduces the iOS 7 rewrite of Terminology (App Store):
Terminology starts with a great offline U.S. English dictionary-thesaurus built around exploring word relationships. Its concise definitions are complimented by deep heirarchical information about the language – with not just synonyms and antonyms, but more and less specific terms, member/part relationships and more.
Gabe Weatherhead:
There are fair number of installable queries and more are available everyday through the action library. But why stop there. Have your way with Terminology and mold it into your own general query tool with custom URLs.
I see it like a LaunchBar for iOS.
Dictionary iOS iOS 7 iOS App Terminology App
Craig Heffner:
In other words, if your browser’s user agent string is “xmlset_roodkcableoj28840ybtide” (no quotes), you can access the web interface without any authentication and view/change the device settings […]
[…]
After some grepping, I found several binaries that appear to use xmlsetc to automatically re-configure the device’s settings (example: dynamic DNS). My guess is that the developers realized that some programs/services needed to be able to change the device’s settings automatically; realizing that the web server already had all the code to change these settings, they decided to just send requests to the web server whenever they needed to change something. The only problem was that the web server required a username and password, which the end user could change.
D-Link Security
Marko Karppinen:
For years, I’ve argued that choosing Newsstand is the best thing—the right thing—to do when publishing periodical content within the Apple ecosystem. But with the redesigned app, and with automatic content downloads no longer a being a Newsstand exclusive, the balance has finally shifted.
We think publishers should skip Newsstand and publish their iOS apps as regular non-Newsstand apps instead.
There is one final reason for this recommendation. If you publish your app outside the Newsstand section, you can always switch to Newsstand later. The opposite is not true.
Update (2013-10-16): Glenn Fleishman:
Put bluntly, Newsstand is a ghetto. Readers complain to me regularly about forgetting to read The Magazine, even though we use iOS notifications for each issue. If readers don’t read immediately and don’t remember to tap the Newsstand icon later, they forget about us entirely.
Update (2013-10-18): Glenn Fleishman:
I realized that I could provide a way to link our Web site to the app via an icon through a simple Web page. I create a page that has the app icons referenced in the top, but also uses the ancient “refresh” option: a browser waits a specified number of seconds and then redirects to a specified URL. Apps can have a URL schema name in iOS; The Magazine’s is the-magazine.
Thus, I created a page that, when visited, automatically redirects the browser instantly to the-magazine:// — this opens the app if it’s installed in iOS. That doesn’t seem useful, though, right? The point is to get an app icon on the home screen! Ah, but it does work. It just takes an extra step for the user.
Update (2014-04-28): Jason Snell:
Newsstand was one of iOS 5’s banner features when it was introduced back in 2011, but its time has come and gone. What was intended to be a special collection of apps has, instead, become a second-class collection. That’s why it would be better for everyone concerned—Apple, users, app developers, and publishers (including Macworld)—if Newsstand just vanished.
iOS iOS 7 Newsstand
Benny Kjær Nielsen:
Recently I became aware of a couple of alternatives. This happened when a MailMate user was not satisfied with my standard Fastmail reply. Among his most interesting findings were Cotse.Net and LuxSci. They are interesting, because they use two of the most reliable IMAP server implementations. They use Dovecot and Panda, respectively. Dovecot is my personal favorite and it’s running on my own server. Panda was created by the inventor of IMAP, Mark Crispin.
Dovecot E-mail Fastmail IMAP
Buzz Andersen:
If this is true, and I suspect it is, I think it lends credence to what I’ve suspected all along: iOS 7 is not quite the coherent product of a forceful design vision that we’re led to believe, but rather a somewhat uneven and scattershot response to what Apple perceives as the general direction of its ecosystem as increasingly driven by independent developers.
Apple Design iOS iOS 7
Ellis Hamburger:
That’s the premise of Square Cash, launching today for all debit card users in the US, using any email service. To use Square Cash, all you do is compose an email to a friend, type the amount you way to pay in the subject title, and cc cash@square.com. If it’s your first time using the service, you’re directed to Square’s website where you type in your debit card number — and you’re done. There are no accounts to create, apps to download, friends to add, surcharges to pay, or bank account numbers to look up.
They also have an iOS app to help send the e-mail. It seems to genuinely be free, although PayPal started out that way, too.
Payments Square
