While discussing a similar subject with someone else, I came to the conclusion that while some of what I mentioned was subject to personal priorities, some are tangible, universal "issues."
The one that's the biggest issue is the storage in the rMBP. When you buy it you get 256MB. So now, a year later, you want to upgrade to 750MB. Where do you go? Who sells them? OWC and who else? No one.
Assuming you find one, how much does it cost? How does that price compare to a "standard" 2.5" SSD of the same speed and capacity?
Once you get over that, what do you do with your old one? Sell it? To whom? The ONLY potential buyer is another rMBP owner, and he already HAS that one and is looking for a bigger one, same as you!
I still contend that going to a unique storage format just to make the stupid thing one-freakin'-eighth of an inch thinner was a really bad trade-off for users.
Apples and oranges. I bought my iPad and my iPhone but at certain times you might let someone use it for a very brief time, even for a few minutes. Sometimes with your permission and sometimes without. For anyone with wives, husbands, girlfriends, boyfriends, or other snooping people that you would prefer not to have full access to your iPhone or iPad I am sure you will understand where I am coming from.
Not to mention the ability to prevent kids from racking up big bills on in-app or other types of purchases by being able to limit that secondary account.
By your logic every family member should have their own Mac and they should disable multiple accounts in OS X.
First of al, it is not my logic, I am just stating obvious Apple logic. And I haven'T talker about macs, t.i., personal computers.
Personally, I couldn't agree more about having this option, but if you go a bit deeper into how iOS is designed, you will see that introducing multiple personal domains is not an trivial task. Apple has simply downplayed importance of it. For now.
I can't believe people are arguing against user accounts on the iPad. All the reasons are nonsense, IMO.
Much greater nonsense is people saying Apple should just make multiple accounts. It clearly shows those people have no clue of whatsoever, how complex that actually is and how many questions and problems it opens. Sure, Google can do it on Android, because they don't care about sandboxing inside domains, they don't care about what will happen to other user when switch to another, they don't care about resources for that matter...Android is Windows for mobile and as such opened for any kind of feature masturbation that "public" wants.
But is useless explaining that to you, because you already decided you want this. I'm sure you will get it eventually, but you will have to wait Apple solves much more important consequential problems before.
So Google figured out these problems on 4.3 and so did Apple on OS X but you think they can't on iOS.... I have no idea how it should be implemented, that was just off the top of my head. But I am sure it could be done. And like other features in iOS that you may not use you would be free to ignore this one as well. It astounds me that people could possibly be against a guest user account. It is like the inmates arguing against changing the jail lunch menu and offer something besides meatloaf on Tuesday since it would cause too much pandemonium.
Google hasn't figured out anything. They just added an option and don't care. In case you forgot: there is no sandboxing on Android. Again, I'm personally not against it, I just know it won't happen on simple user "wish, because it is a very complex thing on iOS and of, course, very trivial on Android for reasons stated above.
Guest account is totally different than multiple users.
Multiple users requires a much more complicated internal file management system, with multiple databases for each profile. Each app has to have its own data profile. What about documents? Can you share them between users? Music, videos?
A guest account could just be similar to parental controls, where you set which apps can and can't be accessed, including Contacts, etc. By default, it probably would disable everything but Safari (no history a la Private Browsing), Camera (a la the current lock-screen camera), Phone (no contacts) and a few other default apps like Weather and Calculator. Any app could be Enabled/Disabled, similar to Location Services.
All this would do would be to hide personal data, not create whole new profiles. Much easier. Would solve the problem of someone needing to use my phone to make a call, or my iPad to browse the web or play Angry Birds.
I pisses me off when you call TC a liar without the slightest idea of what you are talking about.
First, I'm pretty sure Tim can defend himself and doesn't need some anonymous ego-on-the-internet to speak on his behalf. Stick to arguments relevant to the issue and drop the deification-as-de-facto-point. Unless you're a TC confidant you don't know any more than I do so drop the airs.
Second, I have more than the slightest idea what I'm talking about. Tim said it is not possible to build a screen with acceptable battery life, good reliability, decent color saturation and a halfway accurate white point without ambiguous unspecified trade-offs. It is painfully obvious to anyone who simply looks at existing products that those arguments are complete and utter nonsense. Maybe he DOES have something better in mind that ain't ready yet. If he'd said THAT I'd have no quarrel. But that's NOT what he said. He made up a pile of nonsense excuses, and now we have yet another example of how silly that was. Accept it and move on.
Quote:
Originally Posted by Flaneur
And without thinking of their basic strategy
What the hell do *I* care about their "basic strategy?" That's their problem, not mine. Mine is wanting a retina ipad mini and a 5" iphone. If Apple doesn't want to deliver those products, fine, but it's silly to ask me sympathize because it's really hard you know or just wait because Jony thinks he's found a way to to save almost a mwH but the part that makes it possible won't be available until Q3 2014.
Quote:
Originally Posted by Flaneur
or their attention to the kind of detail that no one else even sees, let alone cares about.
It strikes me as rather ridiculous to obsess (and delay) over details no one CARES about because... well, because NO ONE CARES about that detail.
To be fair, I'm sure that's not what you meant. That's just what you wrote. I'm really trying to get through the meaningless generalizations to what you actually mean, but honestly I'm not having much luck since you haven't supplied any specifics at all and base your position (and hostility) only on your assertion that Apple is all like good and everything.
In support of my position I present the new Nexus 7 and the iPad 4 as evidence that it is quite obviously possible to make a screen that meets the stated criteria. Either come up with some proof that Tim was right or get off my back.
Or do it exactly like android does now and has done for a year (Multiple users is not new to 4.3 Google just improved them with 4.3) You don't install an app twice. Its one app per device. The user data is kept separate per user. Apps only show up on users home screens if they 'install' them from the app store. They are kept hidden until then. You never double up on an all. Just the app data. Its brilliant.
OMG....Yeah, it's "brilliant" all right It's just like on desktop OS. However, multiple access points to app break the sandbox rule. People, just get is somehow: iOS is not Android, it is not even OS X....
Not to mention some crazy ideas or special API's for 3rd party developers to setting up access and licensing policy...OMG...
I appreciate the sarcasm, because there's a larger point to be made. Where do hardware OEM's fit in with all of this, when Google, Amazon subsidize their tablet costs for ecosystem revenue? Samsung, Asus get squeezed out, and that's why you don't see these vendors making any headway into the growing tablet market. Samsung gets away with it in the phone market because of the fragmentation and complexity of the wireless providers. If phones were as dead simple to sell as tablets, Amazon and Google would have squeezed out Samsung as well.
I believe Samsung has and will strongly consider a fork in the future. I doubt they appreciate the maker of their underlying software undercutting their hardware margins.
Maybe he DOES have something better in mind that ain't ready yet. If he'd said THAT I'd have no quarrel. But that's NOT what he said. He made up a pile of nonsense excuses, and now we have yet another example of how silly that was. Accept it and move on
That's the one thing he absolutely can't say, and you know it, if you know how they work at all.
So until they get their screen solution, they're not going to make a thicker, heavier mini. Your proof will arrive in about eight months. Until then I'm going to be on your back whenever you be talking shit like this, 'cause some people are misled by you. I give up on you as accessible to reason.
I was LG…
You were looking at Samsung or Sharp
The rumors hit the streets
And my vote: I'm gonna get left behind (yeah, yeah)
It was like a dream, ghosting LCDs
Oh, no, IGZO, IGZO…
Google hasn't figured out anything. They just added an option and don't care. In case you forgot: there is no sandboxing on Android. Again, I'm personally not against it, I just know it won't happen on simple user "wish, because it is a very complex thing on iOS and of, course, very trivial on Android for reasons stated above.
I think the point needs to be made that this isn't a difficult problem to solve, but it is a difficult problem to solve retrospectively. I think a pretty simple API solution could easily do the trick, but this would have to be forced on devs, as in "in order to make your app iOS 7.x compatible, you must support multiple users." But the problem with that is in the role out. What do you do until apps support the API? Have two copies? What do you do after the app supporting multiple users roles out? Delete the user data? Or does every app have to implement a solution that grabs the data from the older version during the update? That might very well be tricky for some apps. Also, how do you parse the old data between the new users? How does the app know what user data goes where? That is, if there are two copies, how does the app figure out what user gets what data without having access to BOTH copies of the application, and the Apple-specific user info? All of these things are messy, none of the solutions seem to be viable with sandboxing, and it would seem more likely that you'd start with a clean slate instead of trying to work out a half-worthwhile solution to losing old data.
Once you get past that intermediate step it wouldn't be complicated at all to have user verifications pass through an Apple filter at launch, then have the app apply changes to user data in their appropriate bins in accordance with that verification.
All of the mess comes from getting from now, to then, without a clusterfuck.
So, there are two main things.
1) Multiple users could easily be solved with respect to third party apps with APIs, and this would not compromise the "sandboxing" because the user verification would take place on Apple's terms.
2) Getting those APIs into every app in a clean way without losing user data is not at all easy, and undoubtedly some apps would have to be overhauled to get them to work with APIs that were not part of the original spec.
Google hasn't figured out anything. They just added an option and don't care. In case you forgot: there is no sandboxing on Android.
It seems that android apps are very much sandboxed (http://developer.android.com/training/articles/security-tips.html). Or are you using a different definition of sandboxing? Also, Google hasn't had much to figure out on its own, since it can look to OS X for the basic design. Sandboxed apps in the Mac App store handle multiple users without difficulty because user-specific data is stored in each user's own Library directory.
Fair enough, but how did I mislead anyone? I said Cook's excuses were bullshit and the Nexus is more proof of that. Is that not true?
If the mini were to be retinized, it would add weight, to maintain the same battery life. That's a trade-off they don't want for the mini, maybe okay for the iPad 3, where the screen has more impact.
How much would the new Nexus weigh if the glass and case were the same area as the mini? And what is the real battery life?
Regarding multiple users, they aren't technically hard to implement, especially since Darwin already supports them, and it would affect the sandbox model either (case in point: there's a sandbox model in OS X).
The only issue with multiple user accounts is that they don't make much sense on mobile devices and would require running multiple instances of applications on systems that don't have a lot of RAM or secondary storage to spare, but multiple user profiles do. Profiles could be implemented using a second location to store private data, so that the public profile would have no access to anything sensitive and all other profiles would access their own independent storage for profile-specific data. Additionally, Info.plist settings could be added to offer developers the ability to hide their apps in the guest (public-only) profile (useful for Mail, Contacts, Calendar, etc.), and applications should also be able to tell whether they're running in guest or personal modes, so that they could enable certain settings in guest mode (such as Safari's Private Browsing, because a guest's privacy is important, too).
This wouldn't be disruptive or hard to implement either. By default, all applications would save to the public storage so as to not break their current behavior and would require an update to support private storage.
It seems that android apps are very much sandboxed (http://developer.android.com/training/articles/security-tips.html). Or are you using a different definition of sandboxing? Also, Google hasn't had much to figure out on its own, since it can look to OS X for the basic design. Sandboxed apps in the Mac App store handle multiple users without difficulty because user-specific data is stored in each user's own Library directory.
Only mandatory, system closing app data into app domain is sandboxing. only that can assure the user his data cannot be compromised by another app. Sandboxing on mac does handle multiple users and ads a layer of complicity that Apple most probably finds not appropriate for the iOS. And all over again: how will you manage multiple accounts and their opened applications? While this can be obvious on desktop OS's, it makes hell of a differences on mobiles.
I think the point needs to be made that this isn't a difficult problem to solve, but it is a difficult problem to solve retrospectively. I think a pretty simple API solution could easily do the trick, but this would have to be forced on devs, as in "in order to make your app iOS 7.x compatible, you must support multiple users." But the problem with that is in the role out. What do you do until apps support the API? Have two copies? What do you do after the app supporting multiple users roles out? Delete the user data? Or does every app have to implement a solution that grabs the data from the older version during the update? That might very well be tricky for some apps. Also, how do you parse the old data between the new users? How does the app know what user data goes where? That is, if there are two copies, how does the app figure out what user gets what data without having access to BOTH copies of the application, and the Apple-specific user info? All of these things are messy, none of the solutions seem to be viable with sandboxing, and it would seem more likely that you'd start with a clean slate instead of trying to work out a half-worthwhile solution to losing old data.
Once you get past that intermediate step it wouldn't be complicated at all to have user verifications pass through an Apple filter at launch, then have the app apply changes to user data in their appropriate bins in accordance with that verification.
All of the mess comes from getting from now, to then, without a clusterfuck.
So, there are two main things.
1) Multiple users could easily be solved with respect to third party apps with APIs, and this would not compromise the "sandboxing" because the user verification would take place on Apple's terms.
2) Getting those APIs into every app in a clean way without losing user data is not at all easy, and undoubtedly some apps would have to be overhauled to get them to work with APIs that were not part of the original spec.
This is all true and speaks for itself about complexity that is much wider than sheer technical implementation and from my opinion it's not worth it. However, the guest account in simple form, similar to parental controls as @pendergast (I , believe) mentioned to day would be good enough to sovle most of the problems that arise on single user system.
Comments
Quote:
Originally Posted by PhilBoogie
To me, your points are mood.
While discussing a similar subject with someone else, I came to the conclusion that while some of what I mentioned was subject to personal priorities, some are tangible, universal "issues."
The one that's the biggest issue is the storage in the rMBP. When you buy it you get 256MB. So now, a year later, you want to upgrade to 750MB. Where do you go? Who sells them? OWC and who else? No one.
Assuming you find one, how much does it cost? How does that price compare to a "standard" 2.5" SSD of the same speed and capacity?
Once you get over that, what do you do with your old one? Sell it? To whom? The ONLY potential buyer is another rMBP owner, and he already HAS that one and is looking for a bigger one, same as you!
I still contend that going to a unique storage format just to make the stupid thing one-freakin'-eighth of an inch thinner was a really bad trade-off for users.
Quote:
Originally Posted by gwmac
Apples and oranges. I bought my iPad and my iPhone but at certain times you might let someone use it for a very brief time, even for a few minutes. Sometimes with your permission and sometimes without. For anyone with wives, husbands, girlfriends, boyfriends, or other snooping people that you would prefer not to have full access to your iPhone or iPad I am sure you will understand where I am coming from.
Not to mention the ability to prevent kids from racking up big bills on in-app or other types of purchases by being able to limit that secondary account.
By your logic every family member should have their own Mac and they should disable multiple accounts in OS X.
First of al, it is not my logic, I am just stating obvious Apple logic. And I haven'T talker about macs, t.i., personal computers.
Personally, I couldn't agree more about having this option, but if you go a bit deeper into how iOS is designed, you will see that introducing multiple personal domains is not an trivial task. Apple has simply downplayed importance of it. For now.
Quote:
Originally Posted by MacRulez
Apparently their customers see them differently:
http://appleinsider.com/articles/13/07/22/apple-refunds-6131-itunes-bill-for-8-year-olds-unauthorized-in-app-purchases
this problem cannot be solved only by creating multiple accounts. there are certain additional options parent wants to have for child on App Store.
Quote:
Originally Posted by Rogifan
I can't believe people are arguing against user accounts on the iPad. All the reasons are nonsense, IMO.
Much greater nonsense is people saying Apple should just make multiple accounts. It clearly shows those people have no clue of whatsoever, how complex that actually is and how many questions and problems it opens. Sure, Google can do it on Android, because they don't care about sandboxing inside domains, they don't care about what will happen to other user when switch to another, they don't care about resources for that matter...Android is Windows for mobile and as such opened for any kind of feature masturbation that "public" wants.
But is useless explaining that to you, because you already decided you want this. I'm sure you will get it eventually, but you will have to wait Apple solves much more important consequential problems before.
Quote:
Originally Posted by gwmac
So Google figured out these problems on 4.3 and so did Apple on OS X but you think they can't on iOS...
Google hasn't figured out anything. They just added an option and don't care. In case you forgot: there is no sandboxing on Android. Again, I'm personally not against it, I just know it won't happen on simple user "wish, because it is a very complex thing on iOS and of, course, very trivial on Android for reasons stated above.
Quote:
Originally Posted by Pendergast
Guest account is totally different than multiple users.
Multiple users requires a much more complicated internal file management system, with multiple databases for each profile. Each app has to have its own data profile. What about documents? Can you share them between users? Music, videos?
A guest account could just be similar to parental controls, where you set which apps can and can't be accessed, including Contacts, etc. By default, it probably would disable everything but Safari (no history a la Private Browsing), Camera (a la the current lock-screen camera), Phone (no contacts) and a few other default apps like Weather and Calculator. Any app could be Enabled/Disabled, similar to Location Services.
All this would do would be to hide personal data, not create whole new profiles. Much easier. Would solve the problem of someone needing to use my phone to make a call, or my iPad to browse the web or play Angry Birds.
That't smart talking.
Quote:
Originally Posted by Flaneur
I pisses me off when you call TC a liar without the slightest idea of what you are talking about.
First, I'm pretty sure Tim can defend himself and doesn't need some anonymous ego-on-the-internet to speak on his behalf. Stick to arguments relevant to the issue and drop the deification-as-de-facto-point. Unless you're a TC confidant you don't know any more than I do so drop the airs.
Second, I have more than the slightest idea what I'm talking about. Tim said it is not possible to build a screen with acceptable battery life, good reliability, decent color saturation and a halfway accurate white point without ambiguous unspecified trade-offs. It is painfully obvious to anyone who simply looks at existing products that those arguments are complete and utter nonsense. Maybe he DOES have something better in mind that ain't ready yet. If he'd said THAT I'd have no quarrel. But that's NOT what he said. He made up a pile of nonsense excuses, and now we have yet another example of how silly that was. Accept it and move on.
Quote:
Originally Posted by Flaneur
And without thinking of their basic strategy
What the hell do *I* care about their "basic strategy?" That's their problem, not mine. Mine is wanting a retina ipad mini and a 5" iphone. If Apple doesn't want to deliver those products, fine, but it's silly to ask me sympathize because it's really hard you know or just wait because Jony thinks he's found a way to to save almost a mwH but the part that makes it possible won't be available until Q3 2014.
Quote:
Originally Posted by Flaneur
or their attention to the kind of detail that no one else even sees, let alone cares about.
It strikes me as rather ridiculous to obsess (and delay) over details no one CARES about because... well, because NO ONE CARES about that detail.
To be fair, I'm sure that's not what you meant. That's just what you wrote. I'm really trying to get through the meaningless generalizations to what you actually mean, but honestly I'm not having much luck since you haven't supplied any specifics at all and base your position (and hostility) only on your assertion that Apple is all like good and everything.
In support of my position I present the new Nexus 7 and the iPad 4 as evidence that it is quite obviously possible to make a screen that meets the stated criteria. Either come up with some proof that Tim was right or get off my back.
Quote:
Originally Posted by NexusPhan
Or do it exactly like android does now and has done for a year (Multiple users is not new to 4.3 Google just improved them with 4.3) You don't install an app twice. Its one app per device. The user data is kept separate per user. Apps only show up on users home screens if they 'install' them from the app store. They are kept hidden until then. You never double up on an all. Just the app data. Its brilliant.
OMG....Yeah, it's "brilliant" all right
Not to mention some crazy ideas or special API's for 3rd party developers to setting up access and licensing policy...OMG...
Quote:
Originally Posted by matrix07
Samsung will love this!
I appreciate the sarcasm, because there's a larger point to be made. Where do hardware OEM's fit in with all of this, when Google, Amazon subsidize their tablet costs for ecosystem revenue? Samsung, Asus get squeezed out, and that's why you don't see these vendors making any headway into the growing tablet market. Samsung gets away with it in the phone market because of the fragmentation and complexity of the wireless providers. If phones were as dead simple to sell as tablets, Amazon and Google would have squeezed out Samsung as well.
I believe Samsung has and will strongly consider a fork in the future. I doubt they appreciate the maker of their underlying software undercutting their hardware margins.
That's the one thing he absolutely can't say, and you know it, if you know how they work at all.
So until they get their screen solution, they're not going to make a thicker, heavier mini. Your proof will arrive in about eight months. Until then I'm going to be on your back whenever you be talking shit like this, 'cause some people are misled by you. I give up on you as accessible to reason.
Uncanny. But canny nevertheless.
Quote:
Originally Posted by Flaneur
I'm going to be on your back whenever you be talking shit like this, 'cause some people are misled by you.
Fair enough, but how did I mislead anyone? I said Cook's excuses were bullshit and the Nexus is more proof of that. Is that not true?
I don't know the REAL reason any more than anyone else. That doesn't change the fact that we DO know that his STATED reasons were baloney.
Quote:
Originally Posted by Flaneur
I give up on you as accessible to reason.
Aw c'mon, at least try it first! How do you know until you actually present a reasoned argument?
I think the point needs to be made that this isn't a difficult problem to solve, but it is a difficult problem to solve retrospectively. I think a pretty simple API solution could easily do the trick, but this would have to be forced on devs, as in "in order to make your app iOS 7.x compatible, you must support multiple users." But the problem with that is in the role out. What do you do until apps support the API? Have two copies? What do you do after the app supporting multiple users roles out? Delete the user data? Or does every app have to implement a solution that grabs the data from the older version during the update? That might very well be tricky for some apps. Also, how do you parse the old data between the new users? How does the app know what user data goes where? That is, if there are two copies, how does the app figure out what user gets what data without having access to BOTH copies of the application, and the Apple-specific user info? All of these things are messy, none of the solutions seem to be viable with sandboxing, and it would seem more likely that you'd start with a clean slate instead of trying to work out a half-worthwhile solution to losing old data.
Once you get past that intermediate step it wouldn't be complicated at all to have user verifications pass through an Apple filter at launch, then have the app apply changes to user data in their appropriate bins in accordance with that verification.
All of the mess comes from getting from now, to then, without a clusterfuck.
So, there are two main things.
1) Multiple users could easily be solved with respect to third party apps with APIs, and this would not compromise the "sandboxing" because the user verification would take place on Apple's terms.
2) Getting those APIs into every app in a clean way without losing user data is not at all easy, and undoubtedly some apps would have to be overhauled to get them to work with APIs that were not part of the original spec.
Quote:
Originally Posted by poksi
Google hasn't figured out anything. They just added an option and don't care. In case you forgot: there is no sandboxing on Android.
It seems that android apps are very much sandboxed (http://developer.android.com/training/articles/security-tips.html). Or are you using a different definition of sandboxing? Also, Google hasn't had much to figure out on its own, since it can look to OS X for the basic design. Sandboxed apps in the Mac App store handle multiple users without difficulty because user-specific data is stored in each user's own Library directory.
If the mini were to be retinized, it would add weight, to maintain the same battery life. That's a trade-off they don't want for the mini, maybe okay for the iPad 3, where the screen has more impact.
How much would the new Nexus weigh if the glass and case were the same area as the mini? And what is the real battery life?
That's all the reasoning I got for tonight.
Regarding multiple users, they aren't technically hard to implement, especially since Darwin already supports them, and it would affect the sandbox model either (case in point: there's a sandbox model in OS X).
The only issue with multiple user accounts is that they don't make much sense on mobile devices and would require running multiple instances of applications on systems that don't have a lot of RAM or secondary storage to spare, but multiple user profiles do. Profiles could be implemented using a second location to store private data, so that the public profile would have no access to anything sensitive and all other profiles would access their own independent storage for profile-specific data. Additionally, Info.plist settings could be added to offer developers the ability to hide their apps in the guest (public-only) profile (useful for Mail, Contacts, Calendar, etc.), and applications should also be able to tell whether they're running in guest or personal modes, so that they could enable certain settings in guest mode (such as Safari's Private Browsing, because a guest's privacy is important, too).
This wouldn't be disruptive or hard to implement either. By default, all applications would save to the public storage so as to not break their current behavior and would require an update to support private storage.
Quote:
Originally Posted by d4NjvRzf
It seems that android apps are very much sandboxed (http://developer.android.com/training/articles/security-tips.html). Or are you using a different definition of sandboxing? Also, Google hasn't had much to figure out on its own, since it can look to OS X for the basic design. Sandboxed apps in the Mac App store handle multiple users without difficulty because user-specific data is stored in each user's own Library directory.
Only mandatory, system closing app data into app domain is sandboxing. only that can assure the user his data cannot be compromised by another app. Sandboxing on mac does handle multiple users and ads a layer of complicity that Apple most probably finds not appropriate for the iOS. And all over again: how will you manage multiple accounts and their opened applications? While this can be obvious on desktop OS's, it makes hell of a differences on mobiles.
Quote:
Originally Posted by DeanSolecki
I think the point needs to be made that this isn't a difficult problem to solve, but it is a difficult problem to solve retrospectively. I think a pretty simple API solution could easily do the trick, but this would have to be forced on devs, as in "in order to make your app iOS 7.x compatible, you must support multiple users." But the problem with that is in the role out. What do you do until apps support the API? Have two copies? What do you do after the app supporting multiple users roles out? Delete the user data? Or does every app have to implement a solution that grabs the data from the older version during the update? That might very well be tricky for some apps. Also, how do you parse the old data between the new users? How does the app know what user data goes where? That is, if there are two copies, how does the app figure out what user gets what data without having access to BOTH copies of the application, and the Apple-specific user info? All of these things are messy, none of the solutions seem to be viable with sandboxing, and it would seem more likely that you'd start with a clean slate instead of trying to work out a half-worthwhile solution to losing old data.
Once you get past that intermediate step it wouldn't be complicated at all to have user verifications pass through an Apple filter at launch, then have the app apply changes to user data in their appropriate bins in accordance with that verification.
All of the mess comes from getting from now, to then, without a clusterfuck.
So, there are two main things.
1) Multiple users could easily be solved with respect to third party apps with APIs, and this would not compromise the "sandboxing" because the user verification would take place on Apple's terms.
2) Getting those APIs into every app in a clean way without losing user data is not at all easy, and undoubtedly some apps would have to be overhauled to get them to work with APIs that were not part of the original spec.
This is all true and speaks for itself about complexity that is much wider than sheer technical implementation and from my opinion it's not worth it. However, the guest account in simple form, similar to parental controls as @pendergast (I , believe) mentioned to day would be good enough to sovle most of the problems that arise on single user system.
I didn't think anyone would know what the song was!
Beatles-She Loves You?