IOS 5's "Cleaning" Behavior
marco.org
marco.org
There is a category of data that is aimed at offline use. Streaming apps like Spotify, that let you download playlists for offline use. GPS apps that download hundreds of MB of map data. You get the idea.
On one hand, this data is a form of cache. The data is always available elsewhere (on the content provider servers) and it can be restored if necessary in a worst case scenario. But the key word here is "offline". This is the kind of data that, by definition depends on being around if the user is offline and therefore cannot be easily restored on demand, when the user needs it.
Obviously, having all of this stuff backed up to iCloud and using up GBs of people's capacity is not feasible or even logical. So this kind of data does not belong anywhere that iCloud will back up. But it must be stored somewhere that is safe from being purged.
Yes, a users GPS maps can be restored eventually but that doesn't help them when they are stranded in the middle of nowhere with nothing but a weak GPRS signal and all of their maps gone.
Apple have made an almighty cockup in overlooking the "offline data" use case.
In Marco's case, I'd agree that the articles represent user data that should be stored somewhere like Application Support, which will be backed by iCloud but I think that's probably fine in this case.
* the lack of persistent, non backable offline storage * the addition of a auto-cleaning procedure
The auto-cleanup without a storage alternative is a blunder. iOS 5 decides for the user what should be deleted to free up space. An alternative would be to prompt what application data you would like to remove instead of a blind decision. Otherwise, that's the kind of programming that will one day lead robots to cleanup the human race! ;)
Of course, having permanent local storage that's not backed up would be a more user-friendly solution. However, it would probably lead people to run out of space when developers begin abusing it like some did with temp or cache storage.
It seems like a trend at Apple these days. With Lion, the OS now decides when an application should quit when unused.
With respect to point #1, and in the context of what Instapaper is for, the user is intending to read an article offline, and the local copy of the article was generated by the user's intent (and can, therefore, be considered user-generated even though the user is not the author of the article.)
With respect to point #2, the articles fail the "can be downloaded again" test in light of the app's purpose of making the articles available to the user when the network is not available. When the network is unavailable, the articles cannot be downloaded again. Edit: JeffDClark makes another excellent point here that the article may have originally been behind a paywall and therefore cannot be guaranteed to be re-downloadable. The same is true if the author removed the original article from their webserver.
Ergo, put them in the Documents folder. Whether this would satisfy the app reviewer is another question, but it's worth a shot to carefully explain to them how your app is not violating the letter of the law.
Same result, without long backup times, Apple server bandwidth usage and your iCloud storage usage.
My premise, in point #2, is that this actually isn't the case with respect to Instapaper's raison d'être. In fact, that's sort of the premise behind much of Marco's post too.
That's kind-of the issue though, is it not? One of Instapaper's strength is that it provides for reading in a nicely formatted and offline way. You don't need a connection to go through your IP stack, unless iOS has decided to clean out everything.
His point is, if you back it up to iCloud, to get any use out of the backup, you need to be online. Therefore it's a waste, because in that scenario, you can just download it from Instapaper anyways.
I don't care how Apple (or Marco) solves the problem, but I sure do not want to lose Instapaper articles at random.
I think that has to be the best solution. It's far better to just have everything sync to iCloud and let the user choose to disable it rather than having Instapaper's primary core functionality - being able to read articles offline - not work properly.
I wonder if there is any chance that Apple will change how this works - it seems like this should be doomsday for a large swath of apps.
(married to Smokey and partner on all these apps!)
From what I see, your users have 3 choices: They can use your app and use up their iCloud allotment, they can use your app and not upgrade, or they can upgrade and find a mapping app that is more efficient in its use of space.
It isn't like Chrome where there are rolling updates that just get applied. You actually have to sit at your computer for a while, download the software and than install it. Many chances to turn back.
There is no current safe place to save local data that should not be backed up to iCloud.
The mental model for iOS is that it stores only two kinds of data: discardable because it can be reproduced, and backed up because it cannot.
That ensures that all your data always is safe. You do not have to worry about losing data when your phone breaks down, or about forgetting to move some data when you upgrade.
I think this also is the reason iOS devices do not have memory card slots. It complicates data management; Apple does not think that is worth the extra complexity.
That could still be persisted separately if you stuff all that into iCloud's KV store instead of relying on file backup. (Just trying to brainstorm technical solutions; not suggesting they're at all optimal.)
The app: webalbumsapp.com
That is the title of Apple's main iCloud page at http://www.apple.com/icloud/.
iCloud is seamlessly integrated into your apps, so you can access your content on all your devices.
This is Apple's definition for the iCloud service. It doesn't matter what the data is, it's your data and Apple is promising to sync it between your devices, to preserve your experience.
In the case of Instapaper, the solution is obvious: Put the files in Documents. That is Instapaper's content and part of the experience that users want synced between devices.
If Apple penalizes developers and undermines the promise it is making to users because it decides to be miserly about bandwidth, then it has to admit it launched iCloud before it was ready.
That's the key right there. The size of the Instapaper database is determined by the user. It will only fill up a user's iCloud space if they decide to save a lot of documents. Plus, they always have the option to buy additional space!
Aside from making sure the documents are reasonably compressed, the size of the Instapaper database should not be Marco's concern.
If you go to the bottom of http://www.apple.com/icloud/features/documents.html you can see the web interface you have to use.
I know this is a tangent to the OP but I was very annoyed to discover this last night, I feel like Apple was pretty misleading here. There are clearly technical difficulties that still need to be surmounted.
1. Only documents and other data that is user-generated, or that cannot otherwise be recreated by your application, should be stored in the <Application_Home>/Documents directory and will be automatically backed up by iCloud.
2. Data that can be downloaded again or regenerated should be stored in the <Application_Home>/Library/Caches directory. Examples of files you should put in the Caches directory include database cache files and downloadable content, such as that used by magazine, newspaper, and map applications.
I don't know if this is something enforced in the approval process, but it seems like Apple's intention is for redownloadable content to all be stored in temporary, wipeable locations.
One can probably easily imagine an interface for showing the user how much data a particular app is using and allow them to nuke the temporary stuff. It might even look beautiful. It might even be fun to use. But it's going to introduce a lot of hand-wringing and micro-managing and lots of mental overhead that Apple really, really wants to avoid.
On the other hand, if users and developers in a community are free to view, modify and share the source code of the operating system and programs they are using, then that creates a dynamic where software cannot remain defective by design, something which cannot be said about Apple's hardware or software.
If we were talking about free (as in speech) software, users would have control of their data, and their choice of how to manage it; not some distant programmers working for a corporation's bottom line.
Circumventing design decicions is hard. Learning the specifics of particular design is hard practically in the same way. Hacking in an intentionally prohibitive environment is not much different from hacking in an overtly permissive environment — there's a pile of poorly undocumented design decisions which you have to grock before you get anywhere in this system.
So the actual difference it political. I won't argue that preventing little Joe to write the coolest Doom clone ever by requiring all software to be cryptographically signed before running it on a particular game console is somehow more evil than forcing him to spend years learning the ropes and working late hours in QA.
But I believe that imposing certain constrains on people willing to build on your platform is a good thing, because the resulting uniformity gives the platform more leverage. Whethere the constraints are technical or political /in origin/ is irrelevant.
Oh, so is that like having freedom from porn now?
Well, it is a lot like freedom from worry about what your 10-year-old is doing with the iPhone you bought them.
As long as someone offers devices that give you the abilities you want, why begrudge people who want something different?
Point is, such didactic statements are stupid, as is the whole 'less choice is actually more freedom' mantra.
Put it this way. Say the government mandated one phone. One car. One style of house. One fashion outfit. You don't need any more than that. You're freed from having to micromanage your stuff. Sure, you can wear your outfit any way you want, and get your one car in whatever colour, but hey, uniformity breeds freedom from the enduser, right? Because 'micromanagement' is bad, right?
There's a happy middle, and I think we're approaching it (given the mobile ecosystem, from both sides). I enjoy using iOS, and for most of my apps I don't care where they store it. I do agree that there appears to be a design flaw in iOS surrounding this, but allowing users complete control over their system only allows them (including me) a greater opportunity to shoot themselves in the foot.
... but I am free to do all of those, plus free to modify all of those in the way I choose, should I want a better fit. Sure, I may have to be a dev, and have background knowledge in how to engage in some of those, but the capability is there. Granny Jones isn't going to shoot herself in the foot because of some downloaded maps.
Now, how about some real freedom. Like the freedom to choose the mobile OS you want, be it "restricted" iOS or "open" Android, or whatever.
Yes, clearly restrictions for the space available to apps on a mobile phone is the same as political totalitarianism.
And user space apps not being able to address/change kernel space in Unix is also a major blow to our freedom.
I'm trying to say that choice is not equivalatable to micromanagement - if it was, and the elimination of micromanagement is good, then the elimination of choice would be good - which it patently isn't. You have choice over a great many things in your life which are trivial, yet which people find important to have.
It was an analogy - "put it this way. say the X" kinda makes that clear.
This "freedom" is reserved for a very, very small class of people. Conversely, as much as you might not like it, an experience that hand-holds offers a kind of freedom for people who wouldn't otherwise be able to take advantage of modern hardware and/or software.
In theory, there doesn't have to be such a dichotomy between freedom and superior polish/UX. In practice, I feel strongly that there is. The popularity of such hand-holding, "freedom"-restricting devices is also highly suggestive.
Depending on where you sit, Android seems to bridge the gap, but as an Android user for years, I'm not completely convinced it's a superior experience.
I'm not unsympathetic, but I think the above view is detached from the reality of modern computing as the majority of people experience it.
Every non-apple developer and user is required to bend to
the will of the programmers who develop the proprietary
iOS.
Every non-developer user is required to bend to the will
of the programmers who develop the OS.
Developers are not users. I don't particularly want my mobile phone to respect the "freedom of its developers". I do want to be sure that no app I install at a whim hogs the disk down, installs spyware or f*ks the phone when I'm in need to make an important call. If I wanted "developer freedom" I'd choose OpenMoko. Strangely, millions of us did not.
> Every non-apple developer and user is required to bend to the will of the programmers who develop the proprietary iOS.
He's only "required" so if he chooses to use iOS. And if he chooses to use iOS, it's because the platform attracted him, and one thing that attracts a lot of people to it it's the "it just works" and "you don't have to manage it".
> Any negative choices or limitations imposed by Apple Inc. are virtually uncircumventable.
Yeah. Except if you jailbreak.
> On the other hand, if users and developers in a community are free to view, modify and share the source code of the operating system and programs they are using, then that creates a dynamic where software cannot remain defective by design, something which cannot be said about Apple's hardware or software.
Yes. Then you get the mighty OpenMoko. Not defective by design. Yay!
> If we were talking about free (as in speech) software, users would have control of their data, and their choice of how to manage it; not some distant programmers working for a corporation's bottom line.
Yes, for a brief time in college I'd quote RMS too. You'll get over it.
That is entirely true, and yes that is part of the problem. The polished nature of a proprietary operating system is like a polished jail. It may be nice and roomy now, but what about in 5 or 10 years when everyone has an iPhone and Apple has one or no competitors? Can we stop them from shrinking our room if there is no free alternative?
> Except if you jailbreak
Actually, no. You can access the filesystem, but you can't install your own free (or proprietary) operating system on the iPhone because there isn't one.
Free software isn't all about nice looking features (though they tend to get developed in time), it's largely about creating a dynamic that ensures the freedom of the user, and that protects them from anti-features, both blatant and subtle. It may not sound like much on the surface, but it's an important issue, especially if someday someone in power says that they don't approve of what you do with your computing devices.
The user of a program is controlled by the program and the program is controlled by the programmer. Do you wish to be controlled by someone who won't show you what the program does, and doesn't allow others to make improvements? There _are_ alternatives, and they are not perfect. I don't expect everyone to be an early adopter of every free technology, but there are many, especially at HN, who would be able to use them and to help them grow to the point where most people would be able to use them quite easily. Developing free software is an act of generosity, because it is much needed in our world, where we are becoming so dependent upon computing technology.
Well, for one our room was fairly small itself before the iPhone. Actually, not small --inexistent. The only reason the touch-smartphone room exists is because Apple made the iPhone and then everybody copied it. So, if they have no competitor in 10 years, more power to them.
But I think that that can't happen. Even MS at the height of its power has had competitors... And today we have Android in several versions already.
> Actually, no. You can access the filesystem, but you can't install your own free (or proprietary) operating system on the iPhone because there isn't one.
Why that is? Because the OSF/GNU etc never cared about a mobile OS until Apple made one. Suddenly freedom in the mobile apps was important. Why wasn't it important when Nokia, Sony, Ericsson et al ruled? Because it took Apple (and Google after that) to show that a mobile OS can be a nice platform to use.
Thank you. Nobody wants to remember that.
Is it just me, or has the free software community gotten so disciplined and precise with their talking points that it would make Karl Rove blush?
It comes down to this: different people want different things. Some people want Kramer's vision of building your own pizza, both for fun and to get exactly the pizza you want. Most people would rather have pizza driven to their house after a 1 minute phone call, and if they lose some freedom over the exact topping placement and the kind of crust used, they're quite fine with that.
Yeah, this was a really boneheaded platform decision, and I'll be very frustrated if Apple doesn't fix it. But you can't seriously tell me that open-source software doesn't sometimes make blunders or suffer from flawed usability. And the idea that I can theoretically crack open the source to my app (the Venn intersection of those with the time, ability, and willingness to do so are a speck, by the way) doesn't help me after the cache is already cleared while I'm sitting on the plane.
I don't care whether something is defective by design, or defective by lack of design: I care that it's defective, period.
The day that technology vendors start engaging in things like free speech suppression or non-consensual privacy invasion is the day I'm willing to think of computing as being a political issue. What we have here is nothing more than tech which you think sucks, and in this instance, you're very right. If it sucks enough, people will stop buying it, and/or the vendor will make it suck it less. But for god's sake, get off the the soapbox and go back to making things; everybody has exactly as much freedom as they want.
tl;dr: FOSS needs to get better at delivering pizzas instead of bitching about Domino's.
Interesting. As an engineer, I very much care about causes. Especially systematic ones. They allow me to better reason about the kinds of problems my system is likely to have, and to proactively mitigate them.
I believe that sudoman's tl;dr is something like "If Domino's executives ate at Domino's, the pizza would taste better", which is to say that (as for most iOS APIs), Apple's own software almost certainly uses different APIs than what they force developer apps to use.
Even if you don't find comments like that interesting, I do. Your comment however (and the other replies to sudoman) miss the point entirely, and instead of discussing why the Domino's executives don't eat Domino's pizza, you spend your time arguing the importance of executives.
I think it's foolish to think that Apple uses private frameworks for their apps exclusively, when they could be using the public frameworks that other 3rd party apps use.
It's more likely to be: Apple uses the public frameworks for the majority of their apps but use the private frameworks for controlling the underlying hardware and subsystems of the OS [stuff like communications which could cost the user money, SMS, phone calls].
http://fajkowski.com/blog/2009/05/21/clicker-app-rejected-fo...
https://github.com/kennytm/iphone-private-frameworks
http://arstechnica.com/apple/news/2008/12/private-iphone-api...
http://www.tipb.com/2010/04/06/ibooks-private-apis/
http://www.tuaw.com/2009/12/15/apple-relents-and-is-now-allo...
http://gigaom.com/apple/cut-the-drama-people-private-apis-th...
Some APIs are not ready for developer use, end of story. Apple does right to forbid their use to avoid crashes on the next iOS upgrade. It's not some plot to gain advantage. CoverFlow clones were always welcome, page curl is already published (clones were welcome before that, I coded one btw), JSON parser already published, some other APIs have no place on developer space.
Your complain should be: Apple doesn't open source their system.
If they aren't ready, why does apple use them?
> Apple does right to forbid their use to avoid crashes on the next iOS upgrade
Why doesn't this argument apply to apple? Are there any other methods of preventing crashing?
> Your complain should be: Apple doesn't open source their system.
No. My complaint is that apple doesn't treat developers as fellow programmers, but more like "end developers" or something. Apple gets to do it differently. Case in point being OP's post.
> And I don't understand why you post random links about issues you are not familiar with
You're projecting :-/
Example Gnome3, which is free software, even a officially sanctioned GNU project. Overnight, a few key people decide to abandon the traditional desktop metaphor, against the will of a majority of their users and to the detriment of the whole linux desktop. The users hated it and are still hating it, but nobody has the ressources to modify it. Nobody has even the ressources to keep Gnome2 alive, let alone fork Gnome3.
Yes, in theory users could make only those changes they want, but only in theory. In practice, if a significantly influential player says that Gnome2 is gone, Gnome2 is gone. Even if iOS was free software, if Apple decided to make a change, they would be still big enough to force a majority of users to accept their way.
Given that the potential to do something is worth a whole lot less than the activity itself, it's easy to see why FOSS is in is current state and will remain that way for a long time.
If you're not paying for their time (or willing to put your own time in), you don't get to chose how the people who are putting the effort in spend their programming time.
With free software, you have the option to do whatever you like to it, but no-one has the obligation to work on it on your behalf.
Absolutely and that's the problem. Say my wife (not a programmer) doesn't like it, she isn't going to learn to program, understand the code, make the changes she wants and implement them.
While it's theoretically possible, it's so impractical as to effectively be impossible.
The number of people for whom free as in speech software is actually freer than close software is a very small percentage - for others, such as my wife, Android or Linux is no freer (as in speech) than iOS or Windows.
This doesn't take skill in programming, no more than (in the venerable tradition of car metaphors) it takes mechanical skil to know that the dealer can install the leather seat or roof-rack options for your car if you request that of them.
You drastically understate the percentage of people who have alternatives to choose from at their skill level.
I think you're over estimating how IT literate my wife and many others are. I bought her a MacBook because she used to shout at the PC too much.
And it's not just her. My mum wouldn't get a Mac as she didn't want to have to relearn Windows. My aunty had Linux installed by one of her sons on her PC (for security reasons) and couldn't do a thing (another one returned it to Windows so she could go back to reading her mail and looking at the funny things her friends sent her). And before anyone asks about how all these examples are about women, my father is so IT illiterate I can't even form a coherent example of his lack of knowledge because there's so little of it (though he still surfs the web and looks at his photos).
For these people the idea that you'd go and look for an alternative is a pretty big stretch and that's before you ask whether they actually have the skills to carry out a proper assessment of what is available, what meets their needs, what's robust, what's actively developed (a major consideration in the FOSS world) and so on to make a choice. And even if they do do all that suddenly a major part of their world changes and there is (for them) a major investment in relearning how things work.
If you've got the skills and genuinely worry about these things then I agree FOSS is great but for a massive, massive number of people they just want something basic that makes some sensible choices they can live with and get on with doing stuff. Right now that's a need FOSS is doing little to meet.
Not entirely true. Windows can run into licensing problems from time to time, which you don't get with the other major OSes. Buy a used macbook? OS is fine. Buy a used Windows PC? Well... the vendor said it was genuine. Turns out if you try to get the security updates, it starts complaining about not being genuine. I had to sort out exactly this problem for a nontechnical ex-colleague of mine who'd bought such a PC for her new small business.
But I'd say that's a pretty niche scenario. In over 20 years of PC use I can't say that I've ever come across it, either personally or seeing a friend or colleague go through it.
For the most part, it 'just works', but it's not doing so in a legal way.
Those people need to do a total cost of ownership assessment and work out whether they go with something FOSS or something closed. While FOSS is great in cash out the door terms if you value your time it may not be as good a choice.
But again both are scenarios around free as in beer, not free as in speech.
* Incidentally, I should note I'm not against FOSS. I'm typing this into Chrome and I work for a company who build their products using Java and JBoss and who run an extensive Linux infrastructure. For us those have been great decisions but for my family who are not IT literate, I think the FOSS assessment looks very different.
But when she uses a program whose the source code can be examined by a worldwide community of programmers, her chances are greatly improved that if the code plays any dirty tricks someone will already have discovered the offending code, they will have screamed bloody murder, and the offending code will already have been removed. Even if she's unfortunate enough to have encountered the malicious code before it's been discovered, she can be confident that when it is discovered: 1) it will quickly be fixed, and 2) since it's in Microsoft's and Apple's interests to disparage F/OSS software, it will be prominently reported on the 11:00 news.
I'm certainly not claiming that there's any absolute guarantee that any software is safe. If you really want to be paranoid, read Ken Thompson's "Reflections on Trusting Trust" at http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.167....
But I am claiming that her chances of being harmed by having her data misused are far, far greater when she uses software that can only be examined by a very few programmers inside an organization that has a vested interest in hiding the misuse. She's much safer when she uses software that can be examined by a worldwide community of programmers whose vested interest is in achieving status within the programmer community by producing code they can be proud of.
Part of this is that I think the whole "programmers eyes" benefit is over stated.
"Can be examined" and "is examined by people who know enough to do a useful assessment" are different things. The number of programmers who really understand security isn't that high and the number of those who are committing time to review this sort of code is a fraction of this.
Most exploits aren't down to subterfuge, they're down to incompetence and the people coding (and reviewing) Linux are no less prone to that than those working on Windows or OSX. Those programmers are still human and still make mistakes. Oh, and not everyone reviewing the code has my best interests at heart. I'm not saying that security through obfuscation is good (it's not) but nor is openness without some drawbacks - on balance it's good but it's two steps forward, one step back.
And even if there are exploits in there for the NSA and the like, that's not actually that big a deal for most people. Don't get me wrong, I don't subscribe to the "privacy is only for those with something to hide" line, but security is about trade offs, and I can't see that the potentially greater security that comes from the code being open isn't worth the trade offs that come with it for non-technical users.
For me the positive thing about OSS is that to a large degree it keeps the competition honest. OSS keeps a focus on security and openness that I don't think existed in the same way before it was so prominent. I think this is a massive benefit, just one that I don't have to use OSS to take advantage of.
Because of this I love that OSS exists, and benefits from the fact it does, I just don't want to use it.
However, the main point isn't whether we can get as much eye-candy as humanly possible. Free software operating systems may always be lacking some set of features that are present in proprietary systems. But the real issue is how many _anti-features_ there are. We know about Apple's decision on storage policies because it is blatant and they were up-front about it. But there is so much in a proprietary program that we can't easily monitor. It may sound paranoid, but there are likely backdoors, etc. in many of our cell phones, allowing paying governments to listen to converstaions, even when it's sitting in your pocket, or it looks like it's off but still has the battery in. http://www.neatorama.com/2011/05/29/gmail-hackers-used-us-go... Gmail and others are _known_ to have backdoors to user data for governments, for example. How comfortable are you with that?
And it's not limited to backdoors and spying. Apple once installed a hardware chip in one of their computers to remove certain features and sell it at a cheaper price. Removing the chip allowed users to use those features. While we usually don't have much control at the hardware level, I personally don't want to use an operating system that is defective by design http://www.defectivebydesign.org/ , with forced obsolescence just being one example of a dirty tactic that is often used. (Get the latest phone, the previous one isn't cool anymore and the new OS works like crap on your "old" hardware!)
If it weren't for Firefox, there would hardly be any web standards to speak of, and the internet would basically cater to Microsoft Windows' Internet Explorer. Microsoft resisted the development of the internet in its current form because it allows users of virtually any operating system to use the web to its fullest potential. I don't think Apple is very much above that kind of thinking. When there weren't many apps for the iPhone, Apple touted the idea of web-based apps, because it was an easy entry point, and there weren't many binary alternatives in the "ecosystem". Once there were lots of programs in Apple's (censored) store, they began discouraging the use of web-based applications and encouraged everyone to make programs compiled for the iPhone, largely because a user of any device can use a web-based app, but you have to buy an iPhone to use the any of the programs that have been written by programmers for that device. (No cross-compiling allowed by Apple, btw.)
So whether or not we like where development is heading with a given free software project, there is a sanity to the development process in that there are no anti-features that I can really think of. If any get made, then all it takes is _one_ programmer to say, "I don't like that idea, I'll just delete that code and share the change with others, because it suits me, and because I can."
edit: spelling
"Overnight, a few key people decide to abandon the traditional desktop metaphor,
against the will of a majority of their users and to the detriment of the whole
linux desktop. The users hated it and are still hating it..."
- "overnight" - Versus an open discussion among everyone interested, with lots of early prototypes available to discuss the changes.
- "against the majority of their users" - Got numbers? Reasonable surveys? Or are we just trusting that the loud crowd that curses about this change is not a vocal minority, but really 'the userbase'?
- "the detriment of the whole linux desktop" - Puh - lease.. That's not even funny. This part is just sad..
- "Users hated it and are still hating it" - Generalization, care to provide numbers, surveys - ah, right. It's just a repetition of the second point, right? To really make it stick?
Really, that was uncalled for and totally useless. You could've made your point about not being able to 'use the source' without adding unqualified attacks.
edit: I'm shocked this thread is so long and no body mentioned this. It's been on the apple developer forums for months as a solution.
Has anyone used this successfully?
https://twitter.com/#!/marcoarment/status/124587437799374848
In fact, if you use UIManagedDocument, it creates a .nosync directory in the document bundle to prevent it from syncing in the framework itself.
The documentation seems to imply that .nosync will prevent the whole store from being uploaded, but (1) that does not seem consistent with what others are reporting, and (2) I cannot find any other supporting information on .nosync in either Apple documentation or dev forums - that doc and this thread are literally the only places I've seen it referenced.
The other underlying issue is whether Apple would be cool with storing persistent application data in Documents provided that it is not synced to iCloud. The use case that Marco and others have described does not really match what's described in that document.
edit: Marcos -> Marco
They spoke about .nosync at this year's WWDC a few times. Dev forums are a little nuts since they opened the iOS Beta 5 forums to all the non NDA members.
1. Temp: No backup, cleared regularly
2. Cache: No backup, cleared when space is tight
3. Local: Local backup only, never cleared
4. Documents: Local/cloud backup, never cleared
5. Cloud: Cloud backup, cleared when space is tight
The problem seems to be that #3 doesn't exist. Yet you'd think it would be a common requirement for stuff like in-app purchases of large and essential content packs, for example, turn-by-turn navigation maps.
I'd hate to be on holiday and have a 10 megabyte podcast download automatically trigger the erasure of 1000 megabytes of navigation data.
Or to put it another way, if it's important enough to retain when storage space is low, it's important enough to retain for when you have to recover from a backup.
If I stored something specifically for offline use, I want it to be available as long as my device is with me, even when I'm offline. (1) Some of it is important as you say, and they should be backed-up, but (2) some are important, but is capable of being downloaded again and shouldn't be backed up and shouldn't'. The latter is the one that is now automatically cleaned up.
I would guess the idea is to help enable these 500 MB per issue magazine downloads. You download a new issue, you nuke some old issue, no one cares. As long as that wasn't an issue you cared about.
The more storage space taken up by local files being backed up to iCloud, the more people will end up going over their 5GB capacity, and will have to upgrade to the higher capacity plans to cover it. I'm not sure I actually believe this right now, but if they refuse to fix the problem, then I might...
It seems that the argument that only the list of metadata is user-generated can apply to any type of media (music, movies, etc...). Technically speaking all of the music on my phone could be downloaded on demand. Of course this requires an always connected, fat, and cheap network connection. Which is pretty much the opposite of what most folks have.
This also breaks the user's expectations. I was annoyed/surprised when I upgraded to iOS 5 and Instapaper had to re-download everything.
As far as I know, all scraped articles are stored in Instapaper's server and downloaded from there, you don't get them directly from the source page.
The ball is in Apple's court.
To avoid this issue and enjoy the benefits of iOS 5, I'm going to have to clear out a bunch of apps, music, and photos and ensure that I always have a sufficient amount of "buffer" space so the cleaning is never triggered. I cannot be alone in this, and the fact that Apple is making this kind of thinking necessary for end users is kind of ridiculous. I really can't see this behavior lasting for very long, and I'm sure Apple will address it soon; this is the antithesis to the traditional iPhone experience. The only scenario where I could see this being purposeful is if Apple is really trying to hurt offline apps to increase data usage and appease carriers (maybe for pissing them off with iMessage?).
Alternatively, just turn off iCloud back ups.
The argument against that is that you're now syncing that article with iCloud in addition to Instapaper.
But I wonder whether the correct answer is instead to eliminate Instapaper's sync feature, and just let iCloud do it. Once you have system-level cloud sync, don't you want to let Apple do the work? Sync is hard, and it isn't really the core value of Instapaper.
Edit: I was wondering about iCloud only for iOS 5/MacOS 10.7.2 devices with iCloud accounts. But that story does fall apart for people with mixed devices. So never mind.
Maybe Apple will release iCloud for Snow Leopard, but as it is now, instapaper works all the way down to the terrible version 2 iPhone I have had to resort to using in order to not sign into a new contract waiting on the release of the 4s.
Instapaper would hurt too many current users who are just fine with how things work without the cloud.
The relevant part of the documentation is here: http://developer.apple.com/library/mac/#documentation/FileMa...
http://developer.apple.com/library/ios/#DOCUMENTATION/FileMa...
That said, I think we're in the clear with respect to iCloud backups:
"Devices with an active iCloud account have their app data backed up to iCloud at appropriate times. And for devices that are plugged into a computer, iTunes performs an incremental backup of the app’s data files."
It's ambiguous. But "app data" sounds like documents, whereas "app's data files" sounds like big data files in /Library to me.
The articles themselves, yes, send them to the cache. If the user needs to reclaim the storage used up by the articles, let the OS delete them. Then, when the user needs to read the article again, it will take some time to download. But don't get into an "all articles gone" situation. Just my 2 cents.
I'd say in this case, the content is user-generated and should be backed up.
But this does indeed defeat the point of having it offline, which is a significant part of IP's purpose.
This is an interesting twist especially with the 16GB devices which tend to actually be above 50%.
Solution: I disabled backups of rdio data.
That way, the default behavior is that "download something = want to keep it on device", but users can do the other one too if they want. I don't think the option is particularly useful, but it might make the app reviewer happy?
[Edit] Upon further examination of the new Settings/iCloud in iOS 5, what will need to happen is that the user should be able to disable iCloud syncing for individual 3rd party apps. That's the most consistent solution for the current interface. [/Edit]
This is literally exactly how I would implement the choice if I were Marco.
If people don't want the benefit of having their Instapaper content transfers across their devices automatically (and I do think this is a good feature) then they are free to disable iCloud backup for Instapaper in Settings.
(That's a serious question, BTW. I would check it myself but I can't upgrade to iOS5 until I figure out how to get Windows DEP to stop killing iTunes 10.5 every time I launch it.)
Settings > iCloud > Storage and Backup > Manage Storage > [DEVICE] > Backup Options.
In the same way Apple doesn't want every developer operating their own independent payment system, they also don't want developers operating their own cloud storage services. If Apple holds the data they can guarantee its security. They likely see these problems as temporary, until developers and customers learn to adjust to the fact that iOS data is controlled by the iCloud service.
your app absolutely needs tons and tons of data to function? doesn't seem like your day. it's their device, their cloud, their decision. Apple doesn't give a shit about your day; they're going cloud. they may be wrong, but i'd guess they're going to have to find that out for themselves.
i'd assume they acknowledge this may kill some apps. i don't think they ever promised anyone a business; on the contrary, they seem to remind developers that they are there at their good grace all the time. as someone that built Facebook apps since '07, trust me, i know what this is like. start coding and start calling. best of luck.
[1] http://37signals.com/svn/posts/347-youre-not-on-a-fucking-pl...
I just don't buy the lame justification about not always being connected. If you don't want to be connected, turn off your damn phone. Don't insist that everyone else shouldn't be able to enjoy their time the way they want to because you associate your mobile device with stress.
2. It goes against the spirit of Apple's policy here, which is not to backup to iCloud what ca be re-downloaded (see 1)
3. The user might have lots of content stored and again due to 1, those don't need to be backed up to iCloud. And really Instapaper actually has a small version of the problem. What is critical is applications that has huge amounts of data like offline maps and wikipedia. Those can be re-downloaded from their servers yet most definitely should not be backed up to iCloud due to time and cost.
I wonder if OS X, in line with its trend to be more like iOS, is going to start automatically clearing the ~/Library/Caches directory as well.
I'm confused. If the goal is for documents to be available in the near future in offline form, why not keep documents in /Documents until the user has read them (or some sane amount of time has passed), and then move them to /Caches or some temporary storage?
I've never used Instapaper, so perhaps documents are only stored until read anyway?
Perhaps Apple could have made cache cleaning opt-in on a per-app basis until iOS 6, though.
Many people would prefer the old method, where it would say you were out of space, and you would have to go free up some space.
My Nintendo Wii uses a "blocks" concept for this. It works fine, Apple should just copy it.
Would that work?
Of course, one could argue that the cleaning behaviour fundamentally defeats the purpose of a lot of apps, as already covered above (Instapaper, Offline Maps, etc.).
My iMac is packed up for building work, so I can't upgrade my iPad and check this out for myself. Sorry.
Not exactly.
I guess Marco just prefers venting after the fact.
However, he's being asked by multiple people right now for the radar# and he's ignoring the questions. He just said he's known it for two weeks, which might have been too late for Apple to fix it anyway.
As an example, I have a 32GB iPod Touch that I've been using for all of the iOS5 testing for my applications and I'm only using around 600MB total. I'd never run into this issue either unless I loaded this up with tons of other apps and movies and music.
Whether he hits the limit regularly or not is another question...
Why dont you just update your app?