That takes me back.. "I ain't no doc you flea-bitten varmint!" On second thought, maybe Apple should stay away from associations with Yosemite Sam, particularly with all the Bitter Betty's that are still hung up on Apple's latest acquisition.
If Apple specifically made a new UI and for the iPad's version of iOS instead of literally making a larger iPhone OS then I don't think you'll see a unification of Mac OS and iOS apps. I could see them merging even more underlying elements to make it easier for developers which could help attract more Mac buyers but there is no reason to think there all be unified apps. You can look at the MS Surface to see how that isn't exactly a winning formula. I think Cook has even made statements about making the best OS for a particular UI instead of making an "all compromise" solution.
Microsoft's approach was completely different. Initially, they has 2 different OS's for their tablet line. The other issue was it was a desktop OS (Metro) made to work on a tablet. Thus, they were using the single OS approach across many lines.
What I am saying here is that, as Tim Cook said, there will be specific OS's based on the device. OS X for Mac's and iOS for iDevices. However, what I am saying is a coding platform to write a single App that can be used on both iOS and OSX. It would allow you to code apps to take advantage of specifics in each OS. i.e. touch in iOS and mouse in OSX. As you know Apple like to do things in steps and bring customers/developers along for the ride to an easy transition. iOS7 brought resolution Independence to iOS devices. In theory, this would allow programs to be written and auto scaled to the appropriate device. While on the face iOS7 looked to be just a UI change, looking back (if I am right), this was a major step to allow Apple to provide multi-platform coding. This could allow one to write an app for multiple devices/platforms in one shot (iDevice, ATV, max OS X, iWatch?, etc). Not to mention the ability to create larger screen sizes on an iDevice, without having to maintain a specific aspect ratio. This could also be another reason for the 64bit transition. Allowing all of these calculations to be done on the fly, depending on the device itself. Ability to code one App and use on a 64bit iDevice a 64bit OS X device or possibly a new ATV device. Its a unification of a coding platform/development, not a unification of OS's.
Microsoft's approach was completely different. Initially, they has 2 different OS's for their tablet line. The other issue was it was a desktop OS (Metro) made to work on a tablet. Thus, they were using the single OS approach across many lines.
What I am saying here is that, as Tim Cook said, there will be specific OS's based on the device. OS X for Mac's and iOS for iDevices. However, what I am saying is a coding platform to write a single App that can be used on both iOS and OSX. It would allow you to code apps to take advantage of specifics in each OS. i.e. touch in iOS and mouse in OSX. As you know Apple like to do things in steps and bring customers/developers along for the ride to an easy transition. iOS7 brought resolution Independence to iOS devices. In theory, this would allow programs to be written and auto scaled to the appropriate device. While on the face iOS7 looked to be just a UI change, looking back (if I am right), this was a major step to allow Apple to provide multi-platform coding. This could allow one to write an app for multiple devices/platforms in one shot (iDevice, ATV, max OS X, iWatch?, etc). Not to mention the ability to create larger screen sizes on an iDevice, without having to maintain a specific aspect ratio. This could also be another reason for the 64bit transition. Allowing all of these calculations to be done on the fly, depending on the device itself. Ability to code one App and use on a 64bit iDevice a 64bit OS X device or possibly a new ATV device. Its a unification of a coding platform/development, not a unification of OS's.
The coding / platform thing is already like that. Both OS X and iOS have used Objective-C since the launch of the App store(s). If you've written your app well there is little needed to be done to move it from iOS to OS X (most of which is coding the difference in interactions from touch to KB & Mouse) and building a different UI for OS X. After the fact, Swift will be an interesting development to watch and how much easier it will be to make more portable code with it. Anyway, the unification of coding platform has been there, but the Stores are what would need to be unified as well. The only other thing is dealing with the size of a universal binary. Between iPhone and iPad it's not all that big of a deal to include the resources for both UI's, however add in the addition of dealing with another method of input and a much more complex UI and making one binary that is used across iOS and OS X would likely be an issue.
Comments
Probably not going to happen in an OS update.
"Apple is in hot water"
"iOS is dead in the water"
"OS X is becalmed"
????
Looking forward to tomorrow.
The new beleaguered, ladies and gentlemen.
Though ‘league’ works in an oceangoing sense, too.
That takes me back.. "I ain't no doc you flea-bitten varmint!" On second thought, maybe Apple should stay away from associations with Yosemite Sam, particularly with all the Bitter Betty's that are still hung up on Apple's latest acquisition.
I'm surprised that nobody has noted that the 8 used here is not in fact an 8 at all, but a very subtle infinity sign.
What do you suppose that means in the context of an operating system?
Note: One esoteric meaning of this symbol is 'unity'.
Just food for thought.
iOS 8 Infinity Loop
If Apple specifically made a new UI and for the iPad's version of iOS instead of literally making a larger iPhone OS then I don't think you'll see a unification of Mac OS and iOS apps. I could see them merging even more underlying elements to make it easier for developers which could help attract more Mac buyers but there is no reason to think there all be unified apps. You can look at the MS Surface to see how that isn't exactly a winning formula. I think Cook has even made statements about making the best OS for a particular UI instead of making an "all compromise" solution.
Microsoft's approach was completely different. Initially, they has 2 different OS's for their tablet line. The other issue was it was a desktop OS (Metro) made to work on a tablet. Thus, they were using the single OS approach across many lines.
What I am saying here is that, as Tim Cook said, there will be specific OS's based on the device. OS X for Mac's and iOS for iDevices. However, what I am saying is a coding platform to write a single App that can be used on both iOS and OSX. It would allow you to code apps to take advantage of specifics in each OS. i.e. touch in iOS and mouse in OSX. As you know Apple like to do things in steps and bring customers/developers along for the ride to an easy transition. iOS7 brought resolution Independence to iOS devices. In theory, this would allow programs to be written and auto scaled to the appropriate device. While on the face iOS7 looked to be just a UI change, looking back (if I am right), this was a major step to allow Apple to provide multi-platform coding. This could allow one to write an app for multiple devices/platforms in one shot (iDevice, ATV, max OS X, iWatch?, etc). Not to mention the ability to create larger screen sizes on an iDevice, without having to maintain a specific aspect ratio. This could also be another reason for the 64bit transition. Allowing all of these calculations to be done on the fly, depending on the device itself. Ability to code one App and use on a 64bit iDevice a 64bit OS X device or possibly a new ATV device. Its a unification of a coding platform/development, not a unification of OS's.
Microsoft's approach was completely different. Initially, they has 2 different OS's for their tablet line. The other issue was it was a desktop OS (Metro) made to work on a tablet. Thus, they were using the single OS approach across many lines.
What I am saying here is that, as Tim Cook said, there will be specific OS's based on the device. OS X for Mac's and iOS for iDevices. However, what I am saying is a coding platform to write a single App that can be used on both iOS and OSX. It would allow you to code apps to take advantage of specifics in each OS. i.e. touch in iOS and mouse in OSX. As you know Apple like to do things in steps and bring customers/developers along for the ride to an easy transition. iOS7 brought resolution Independence to iOS devices. In theory, this would allow programs to be written and auto scaled to the appropriate device. While on the face iOS7 looked to be just a UI change, looking back (if I am right), this was a major step to allow Apple to provide multi-platform coding. This could allow one to write an app for multiple devices/platforms in one shot (iDevice, ATV, max OS X, iWatch?, etc). Not to mention the ability to create larger screen sizes on an iDevice, without having to maintain a specific aspect ratio. This could also be another reason for the 64bit transition. Allowing all of these calculations to be done on the fly, depending on the device itself. Ability to code one App and use on a 64bit iDevice a 64bit OS X device or possibly a new ATV device. Its a unification of a coding platform/development, not a unification of OS's.
The coding / platform thing is already like that. Both OS X and iOS have used Objective-C since the launch of the App store(s). If you've written your app well there is little needed to be done to move it from iOS to OS X (most of which is coding the difference in interactions from touch to KB & Mouse) and building a different UI for OS X. After the fact, Swift will be an interesting development to watch and how much easier it will be to make more portable code with it. Anyway, the unification of coding platform has been there, but the Stores are what would need to be unified as well. The only other thing is dealing with the size of a universal binary. Between iPhone and iPad it's not all that big of a deal to include the resources for both UI's, however add in the addition of dealing with another method of input and a much more complex UI and making one binary that is used across iOS and OS X would likely be an issue.
-PopinFRESH