I'm not sure how the Mac version of Xcode could ever come to iOS. Even on a 13" MBP where you have a mouse point that can click fine elements separated by only a few pixels it's very cramped. I was forever sliding sidebars in and out. I can't imagine that with my fingers or being forced to use an Apple Pencil to peck around the screen, which means there's no slide or drag or drop without some other button to depress to make iOS know that your Pencil action will be to slide a sidebar into or out of view.
The required UI would involve:
displaying a cursor on the screen
an external kb
a trackpad or mouse
Access to the file system
IMO, these are doable!
I think there will continue to be a degree of OS convergence for Apple and they'll hopefully avoid the mess that Windows has become.
Apple has been very clear that they are not converging their OS X-based OSes. Frankly, it's a ridiculous notion to believe that macOS, iOS, tvOS, watchOS, and their new touchbarOS will all be the same the same download package.
Perhaps... But it is equally ridiculous to believe that Apple can continue to restrict the functionality of its primary OS for much longer without suffering consequences of falling out of date.
I'm not sure how the Mac version of Xcode could ever come to iOS. Even on a 13" MBP where you have a mouse point that can click fine elements separated by only a few pixels it's very cramped. I was forever sliding sidebars in and out. I can't imagine that with my fingers or being forced to use an Apple Pencil to peck around the screen, which means there's no slide or drag or drop without some other button to depress to make iOS know that your Pencil action will be to slide a sidebar into or out of view.
The required UI would involve:
displaying a cursor on the screen
an external kb
a trackpad or mouse
Access to the file system
IMO, these are doable!
I think there will continue to be a degree of OS convergence for Apple and they'll hopefully avoid the mess that Windows has become.
Apple has been very clear that they are not converging their OS X-based OSes. Frankly, it's a ridiculous notion to believe that macOS, iOS, tvOS, watchOS, and their new touchbarOS will all be the same the same download package.
Perhaps... But it is equally ridiculous to believe that Apple can continue to restrict the functionality of its primary OS for much longer without suffering consequences of falling out of date.
None of their OS X-based OSes are "failing out of date." In fact, do you remember when we'd go several years between a major macOS née Mac OS [X] update? Things have never been better for Apple and OSes because of how they can leverage a single core to maximize efficiency, and then have unique builds for the HW and an ideal UI for he primary input. They're also able to rewrite core foundations and apps, and then use parts of that on other OSes to improve its performance. No one else can even come close to this.
I'm not sure how the Mac version of Xcode could ever come to iOS. Even on a 13" MBP where you have a mouse point that can click fine elements separated by only a few pixels it's very cramped. I was forever sliding sidebars in and out. I can't imagine that with my fingers or being forced to use an Apple Pencil to peck around the screen, which means there's no slide or drag or drop without some other button to depress to make iOS know that your Pencil action will be to slide a sidebar into or out of view.
The required UI would involve:
displaying a cursor on the screen
an external kb
a trackpad or mouse
Access to the file system
IMO, these are doable!
I think there will continue to be a degree of OS convergence for Apple and they'll hopefully avoid the mess that Windows has become.
Apple has been very clear that they are not converging their OS X-based OSes. Frankly, it's a ridiculous notion to believe that macOS, iOS, tvOS, watchOS, and their new touchbarOS will all be the same the same download package.
Perhaps... But it is equally ridiculous to believe that Apple can continue to restrict the functionality of its primary OS for much longer without suffering consequences of falling out of date.
None of their OS X-based OSes are "failing out of date." In fact, do you remember when we'd go several years between a major macOS née Mac OS [X] update? Things have never been better for Apple and OSes because of how they can leverage a single core to maximize efficiency, and then have unique builds for the HW and an ideal UI for he primary input. They're also able to rewrite core foundations and apps, and then use parts of that on other OSes to improve its performance. No one else can even come close to this.
Out of date? Even Microsoft has passed them by! And the "Ideal UI" is not the one that you (or Apple) designate. Neither is it the one that makes the hardware happy. It's the one that makes the user happy. Sometimes that means a touch interface and sometimes that means a mouse and cursor -- it depends on the task, not the hardware.
I'm not sure how the Mac version of Xcode could ever come to iOS. Even on a 13" MBP where you have a mouse point that can click fine elements separated by only a few pixels it's very cramped. I was forever sliding sidebars in and out. I can't imagine that with my fingers or being forced to use an Apple Pencil to peck around the screen, which means there's no slide or drag or drop without some other button to depress to make iOS know that your Pencil action will be to slide a sidebar into or out of view.
The required UI would involve:
displaying a cursor on the screen
an external kb
a trackpad or mouse
Access to the file system
IMO, these are doable!
I think there will continue to be a degree of OS convergence for Apple and they'll hopefully avoid the mess that Windows has become.
Apple has been very clear that they are not converging their OS X-based OSes. Frankly, it's a ridiculous notion to believe that macOS, iOS, tvOS, watchOS, and their new touchbarOS will all be the same the same download package.
Perhaps... But it is equally ridiculous to believe that Apple can continue to restrict the functionality of its primary OS for much longer without suffering consequences of falling out of date.
None of their OS X-based OSes are "failing out of date." In fact, do you remember when we'd go several years between a major macOS née Mac OS [X] update? Things have never been better for Apple and OSes because of how they can leverage a single core to maximize efficiency, and then have unique builds for the HW and an ideal UI for he primary input. They're also able to rewrite core foundations and apps, and then use parts of that on other OSes to improve its performance. No one else can even come close to this.
Out of date? Even Microsoft has passed them by! And the "Ideal UI" is not the one that you (or Apple) designate. Neither is it the one that makes the hardware happy. It's the one that makes the user happy. Sometimes that means a touch interface and sometimes that means a mouse and cursor -- it depends on the task, not the hardware.
You think all of MS' OSes integrate with each other better and are more streamlined and modern than what Apple is bringing to the table?
Soli said: I don't get this incessant need for "access to the file system." Why is that necessary?
While I agree with your earlier remarks about the Xcode UI not really very suitable for iOS with all the dragging and miniature controls, but you sort of need a filesystem to be able to create assets in other applications as supporting files like images, sounds, video, databases, etc. You need to drag those elements into your project folder from the file system. If there ever was an Xcode for iOS, Apple would likely insist that it had all the same features as the macOS version because if the iOS version used a completely different methodology it would cease to be Xcode and the project packages probably would not be compatible.
Furthermore, I can't imagine how much of a nightmare it would be coding with an on-screen keyboard. Code differs quite a bit from just writing text because it is completely unforgiving in the way it must be formatted and uses lots of special characters. I hate using iOS for any lengthy documents. It is so tedious.
Even with the Blueprints option in play this is still not feasible for a device where the primary I/O is your finger on a touchscreen. Are you saying you can switch to only Blueprints as your primary UI without all the other clutter that requires a a finer point on a touch element, as well various L/R or Alt/Option buttons with the mouse pointer to make selections for easy coding?
2) Am I wrong in thinking that Apple already has something similar with Storyboards in Xcode?
Storyboards is an example of this, it generates code in the background while manipulating objects in the UI. I think it would be possible to have a primary UI that was much simpler. The XCode UI has a lot of options visible that are never needed to build an app. A visual UI may not be as efficient for good coders but it would be faster to learn for new developers. That's not to say that a pointer option wouldn't help though, I think trackpad support would work quite well but not a mouse cursor as it is strictly singular input, it needs to be multitouch like circles for finger locations on the pad.
I don't get this incessant need for "access to the file system." Why is that necessary? I have dozens folders synced to iCloud. Many of them are Apple's own apps, and within them are files, but also folders that I've created that contain other files for that app. I also have created my own folder at the root of my iClouds folder that contains other folders and files for 3rd-party apps and no specific apps at all.
Of course, all those sync with iCloud, which is a handy feature, but it doesn't have to sync with iCloud. If Apple does offer some sort of Xcode option for iOS-based devices, why can't they just have a similar repository for these development files without Apple specifically creating an iOS app called Finder or one called Terminal so I can bypass a reasonable storage selection, look my how Music is stored in the file system, manually edit PLISTs for Library/Preferences and other such things?
What good reason is there to open this up to over a billion iDevice users. Personally, I think how Apple stores photos and music/movies/TV shows in Photos and iTunes, respectively, is the right way to go. Hell, I want Apple to obfuscate this even more in the future so that macOS is even more user friendly, not less.
I wouldn't expect a filesystem to be opened to all iOS devices, just iPad Pros, which would be a few tens of millions of devices but it wouldn't have to be an app, just a core service and file management would be done indirectly. For example, on macOS, when you download files, they go into the Finder somewhere and all files from all apps go there. On iOS, a core service can have a file space per app so if you wanted to save zip files, images, webarchives from Safari, you'd just be able to save them to the app's file space, ideally in collections and it would be much neater and more contained. These files/collections could be shared between apps.
In the example of code, there may be a project on sourceforge that can be downloaded as a .zip. You'd create a collection in Safari, put the .zip in and extract the files. Hop over to XCode for iOS and allow access to that collection and import the files needed from the archive.
When doing something that needs multiple types of media, a file collection can be shared by an image editing app, an audio app, a text editing app etc.
I'm not sure how the Mac version of Xcode could ever come to iOS. Even on a 13" MBP where you have a mouse point that can click fine elements separated by only a few pixels it's very cramped. I was forever sliding sidebars in and out. I can't imagine that with my fingers or being forced to use an Apple Pencil to peck around the screen, which means there's no slide or drag or drop without some other button to depress to make iOS know that your Pencil action will be to slide a sidebar into or out of view.
The required UI would involve:
displaying a cursor on the screen
an external kb
a trackpad or mouse
Access to the file system
IMO, these are doable!
I think there will continue to be a degree of OS convergence for Apple and they'll hopefully avoid the mess that Windows has become.
Apple has been very clear that they are not converging their OS X-based OSes. Frankly, it's a ridiculous notion to believe that macOS, iOS, tvOS, watchOS, and their new touchbarOS will all be the same the same download package.
Perhaps... But it is equally ridiculous to believe that Apple can continue to restrict the functionality of its primary OS for much longer without suffering consequences of falling out of date.
None of their OS X-based OSes are "failing out of date." In fact, do you remember when we'd go several years between a major macOS née Mac OS [X] update? Things have never been better for Apple and OSes because of how they can leverage a single core to maximize efficiency, and then have unique builds for the HW and an ideal UI for he primary input. They're also able to rewrite core foundations and apps, and then use parts of that on other OSes to improve its performance. No one else can even come close to this.
Out of date? Even Microsoft has passed them by! And the "Ideal UI" is not the one that you (or Apple) designate. Neither is it the one that makes the hardware happy. It's the one that makes the user happy. Sometimes that means a touch interface and sometimes that means a mouse and cursor -- it depends on the task, not the hardware.
Ummmm NOPE Microsoft has not.
I love Windows 10 I think it's their greatest OS EVER but it is so far behind macOS that it is a joke to call it a modern OS.
Metro is a great interface but it can be quite jarring using the same interface on a laptop as on a tablet because they use completely different UIs. That's what got Microsoft in trouble with Windows 8 originally because the tiles structure of Metro apps didn't work well on a mouse driven interface.
Apple have stuck with different interfaces for iOS and macOS because they make sense for the platforms. A convergence of the two WILL NOT WORK because we saw this with Windows 8. There is a precedent as to how bad an idea this is. The fact that you haven't learned this yet is kind of negating your comment.
A mobile device that you carry around with you makes sense to use a finger because you simply don't carry a mouse around with you everywhere you go. Most of the places you use a tablet or phone make using a mouse impossible.
A laptop is largely static even though it can be moved around with ease when you use a laptop you literally stay in one spot because it's easier to use that way. You can make a claim for convertibles but let's face it, Microsoft has been promoting them for over 10 years and they've gained zero traction.
Then of course you have a desktop which is completely static. In both the laptop and desktop cases their static nature makes a mouse more useful and allows a greater precision than a finger can and therefore the heavy lifting makes more sense to be offloaded to a desktop or laptop than a mobile device like a tablet or phone.
The "Ideal UI" therefore IS hardware dependant and not user dependant.
I'm not sure how the Mac version of Xcode could ever come to iOS. Even on a 13" MBP where you have a mouse point that can click fine elements separated by only a few pixels it's very cramped. I was forever sliding sidebars in and out. I can't imagine that with my fingers or being forced to use an Apple Pencil to peck around the screen, which means there's no slide or drag or drop without some other button to depress to make iOS know that your Pencil action will be to slide a sidebar into or out of view.
The required UI would involve:
displaying a cursor on the screen
an external kb
a trackpad or mouse
Access to the file system
IMO, these are doable!
I think there will continue to be a degree of OS convergence for Apple and they'll hopefully avoid the mess that Windows has become.
Apple has been very clear that they are not converging their OS X-based OSes. Frankly, it's a ridiculous notion to believe that macOS, iOS, tvOS, watchOS, and their new touchbarOS will all be the same the same download package.
Perhaps... But it is equally ridiculous to believe that Apple can continue to restrict the functionality of its primary OS for much longer without suffering consequences of falling out of date.
None of their OS X-based OSes are "failing out of date." In fact, do you remember when we'd go several years between a major macOS née Mac OS [X] update? Things have never been better for Apple and OSes because of how they can leverage a single core to maximize efficiency, and then have unique builds for the HW and an ideal UI for he primary input. They're also able to rewrite core foundations and apps, and then use parts of that on other OSes to improve its performance. No one else can even come close to this.
Out of date? Even Microsoft has passed them by! And the "Ideal UI" is not the one that you (or Apple) designate. Neither is it the one that makes the hardware happy. It's the one that makes the user happy. Sometimes that means a touch interface and sometimes that means a mouse and cursor -- it depends on the task, not the hardware.
Ummmm NOPE Microsoft has not.
I love Windows 10 I think it's their greatest OS EVER but it is so far behind macOS that it is a joke to call it a modern OS.
Metro is a great interface but it can be quite jarring using the same interface on a laptop as on a tablet because they use completely different UIs. That's what got Microsoft in trouble with Windows 8 originally because the tiles structure of Metro apps didn't work well on a mouse driven interface.
Apple have stuck with different interfaces for iOS and macOS because they make sense for the platforms. A convergence of the two WILL NOT WORK because we saw this with Windows 8. There is a precedent as to how bad an idea this is. The fact that you haven't learned this yet is kind of negating your comment.
A mobile device that you carry around with you makes sense to use a finger because you simply don't carry a mouse around with you everywhere you go. Most of the places you use a tablet or phone make using a mouse impossible.
A laptop is largely static even though it can be moved around with ease when you use a laptop you literally stay in one spot because it's easier to use that way. You can make a claim for convertibles but let's face it, Microsoft has been promoting them for over 10 years and they've gained zero traction.
Then of course you have a desktop which is completely static. In both the laptop and desktop cases their static nature makes a mouse more useful and allows a greater precision than a finger can and therefore the heavy lifting makes more sense to be offloaded to a desktop or laptop than a mobile device like a tablet or phone.
The "Ideal UI" therefore IS hardware dependant and not user dependant.
MS regularly fails at execution. That's their history -- mediocrity. That doesn't say anything at all though about the concept: That is: a failure to execute does not disprove the concept (especially if you're using MS as an example!)
And, your proof that a laptop can only ever be a laptop and a tablet can only ever be a tablet is a bit like saying: "A phone can only ever be a phone and a web browser can only browse the web -- they cannot ever be joined".
Even with the Blueprints option in play this is still not feasible for a device where the primary I/O is your finger on a touchscreen. Are you saying you can switch to only Blueprints as your primary UI without all the other clutter that requires a a finer point on a touch element, as well various L/R or Alt/Option buttons with the mouse pointer to make selections for easy coding?
2) Am I wrong in thinking that Apple already has something similar with Storyboards in Xcode?
Storyboards is an example of this, it generates code in the background while manipulating objects in the UI. I think it would be possible to have a primary UI that was much simpler. The XCode UI has a lot of options visible that are never needed to build an app. A visual UI may not be as efficient for good coders but it would be faster to learn for new developers. That's not to say that a pointer option wouldn't help though, I think trackpad support would work quite well but not a mouse cursor as it is strictly singular input, it needs to be multitouch like circles for finger locations on the pad.
I don't get this incessant need for "access to the file system." Why is that necessary? I have dozens folders synced to iCloud. Many of them are Apple's own apps, and within them are files, but also folders that I've created that contain other files for that app. I also have created my own folder at the root of my iClouds folder that contains other folders and files for 3rd-party apps and no specific apps at all.
Of course, all those sync with iCloud, which is a handy feature, but it doesn't have to sync with iCloud. If Apple does offer some sort of Xcode option for iOS-based devices, why can't they just have a similar repository for these development files without Apple specifically creating an iOS app called Finder or one called Terminal so I can bypass a reasonable storage selection, look my how Music is stored in the file system, manually edit PLISTs for Library/Preferences and other such things?
What good reason is there to open this up to over a billion iDevice users. Personally, I think how Apple stores photos and music/movies/TV shows in Photos and iTunes, respectively, is the right way to go. Hell, I want Apple to obfuscate this even more in the future so that macOS is even more user friendly, not less.
I wouldn't expect a filesystem to be opened to all iOS devices, just iPad Pros, which would be a few tens of millions of devices but it wouldn't have to be an app, just a core service and file management would be done indirectly. For example, on macOS, when you download files, they go into the Finder somewhere and all files from all apps go there. On iOS, a core service can have a file space per app so if you wanted to save zip files, images, webarchives from Safari, you'd just be able to save them to the app's file space, ideally in collections and it would be much neater and more contained. These files/collections could be shared between apps.
In the example of code, there may be a project on sourceforge that can be downloaded as a .zip. You'd create a collection in Safari, put the .zip in and extract the files. Hop over to XCode for iOS and allow access to that collection and import the files needed from the archive.
When doing something that needs multiple types of media, a file collection can be shared by an image editing app, an audio app, a text editing app etc.
All good points -- except maybe when you suggest that: "On iOS, a core service can have a file space per app". That just sort of made the whole body tighten up - probably because I was indoctrinated into mainframe, enterprise level systems design where a core concept was separation of data from software.
The two were stored separately, never intermixed. So, that enabled a higher level of security in all of its facets (not just from hackers, but it helped to insure the integrity of the data).
The opposite of that is the spreadsheet concept where the software (functions, etc) and the raw data are inextricably intermixed. While that creates some efficiencies and works particularly well in a single user environment, it also creates inherent instabilities where the core data can easily be corrupted with a flick of the finger and protecting the data is particularly difficult.
No, I feel much more comfortable separating software from the data as much as possible... ... My theory is: I can always replace the hardware and software. But not the data Protect the data.
Even with the Blueprints option in play this is still not feasible for a device where the primary I/O is your finger on a touchscreen. Are you saying you can switch to only Blueprints as your primary UI without all the other clutter that requires a a finer point on a touch element, as well various L/R or Alt/Option buttons with the mouse pointer to make selections for easy coding?
2) Am I wrong in thinking that Apple already has something similar with Storyboards in Xcode?
Storyboards is an example of this, it generates code in the background while manipulating objects in the UI. I think it would be possible to have a primary UI that was much simpler. The XCode UI has a lot of options visible that are never needed to build an app. A visual UI may not be as efficient for good coders but it would be faster to learn for new developers. That's not to say that a pointer option wouldn't help though, I think trackpad support would work quite well but not a mouse cursor as it is strictly singular input, it needs to be multitouch like circles for finger locations on the pad.
I don't get this incessant need for "access to the file system." Why is that necessary? I have dozens folders synced to iCloud. Many of them are Apple's own apps, and within them are files, but also folders that I've created that contain other files for that app. I also have created my own folder at the root of my iClouds folder that contains other folders and files for 3rd-party apps and no specific apps at all.
Of course, all those sync with iCloud, which is a handy feature, but it doesn't have to sync with iCloud. If Apple does offer some sort of Xcode option for iOS-based devices, why can't they just have a similar repository for these development files without Apple specifically creating an iOS app called Finder or one called Terminal so I can bypass a reasonable storage selection, look my how Music is stored in the file system, manually edit PLISTs for Library/Preferences and other such things?
What good reason is there to open this up to over a billion iDevice users. Personally, I think how Apple stores photos and music/movies/TV shows in Photos and iTunes, respectively, is the right way to go. Hell, I want Apple to obfuscate this even more in the future so that macOS is even more user friendly, not less.
I wouldn't expect a filesystem to be opened to all iOS devices, just iPad Pros, which would be a few tens of millions of devices but it wouldn't have to be an app, just a core service and file management would be done indirectly. For example, on macOS, when you download files, they go into the Finder somewhere and all files from all apps go there. On iOS, a core service can have a file space per app so if you wanted to save zip files, images, webarchives from Safari, you'd just be able to save them to the app's file space, ideally in collections and it would be much neater and more contained. These files/collections could be shared between apps.
In the example of code, there may be a project on sourceforge that can be downloaded as a .zip. You'd create a collection in Safari, put the .zip in and extract the files. Hop over to XCode for iOS and allow access to that collection and import the files needed from the archive.
When doing something that needs multiple types of media, a file collection can be shared by an image editing app, an audio app, a text editing app etc.
All good points -- except maybe when you suggest that: "On iOS, a core service can have a file space per app". That just sort of made the whole body tighten up - probably because I was indoctrinated into mainframe, enterprise level systems design where a core concept was separation of data from software.
The two were stored separately, never intermixed. So, that enabled a higher level of security in all of its facets (not just from hackers, but it helped to insure the integrity of the data).
The opposite of that is the spreadsheet concept where the software (functions, etc) and the raw data are inextricably intermixed. While that creates some efficiencies and works particularly well in a single user environment, it also creates inherent instabilities where the core data can easily be corrupted with a flick of the finger and protecting the data is particularly difficult.
No, I feel much more comfortable separating software from the data as much as possible... ... My theory is: I can always replace the hardware and software. But not the data Protect the data.
I agree with protecting the data and separation from apps, the system would just be a sandboxed system, not like embedded data. Like how they use containers for Safari Extensions. Access to the iOS containers would be blocked from apps by default for security, unlike in a normal filesystem where any malicious software can erase, encrypt, upload user-level files. Downloads in Safari for example couldn't be accessed by Pages until granted access.
These containers would be separate from the app so that apps could be removed while leaving them in place. They'd be accessible via the core service like the slide-down notifications panel. The benefit of not having it behave like the Finder is that it avoids becoming a dumping ground for files from any app. It makes it easier to navigate and manage when the collections accessible from within an app are the ones relevant to that app. For example, on macOS, you have to go to /Users/<name>/Downloads to get to Safari downloads whereas with app-specific sandboxes, the core service would only show the downloads so it's faster to access and to manage. Safari doesn't need to see the rest of the filesystem by default like it does with the Finder. Pages doesn't need to see Safari downloads by default. They only need to see their own space by default and others when necessary and it means there isn't the same need to tap through lots of folder hierarchies.
It also makes it easier to send files to/from iOS because you could have a sharing system that only accesses a single collection. A movie app can have a collection of clips. Say that footage is on the Mac, the iOS device would be placed nearby, then allow sharing the single collection and it appears on the Mac, have FCPX create proxy files and drop them in the collection. The iOS app now has direct access to all the proxy clips. The iOS app can save an XML edit into the collection, open it on the Mac and it uses the source files for the edit.
Even with the Blueprints option in play this is still not feasible for a device where the primary I/O is your finger on a touchscreen. Are you saying you can switch to only Blueprints as your primary UI without all the other clutter that requires a a finer point on a touch element, as well various L/R or Alt/Option buttons with the mouse pointer to make selections for easy coding?
2) Am I wrong in thinking that Apple already has something similar with Storyboards in Xcode?
Storyboards is an example of this, it generates code in the background while manipulating objects in the UI. I think it would be possible to have a primary UI that was much simpler. The XCode UI has a lot of options visible that are never needed to build an app. A visual UI may not be as efficient for good coders but it would be faster to learn for new developers. That's not to say that a pointer option wouldn't help though, I think trackpad support would work quite well but not a mouse cursor as it is strictly singular input, it needs to be multitouch like circles for finger locations on the pad.
I don't get this incessant need for "access to the file system." Why is that necessary? I have dozens folders synced to iCloud. Many of them are Apple's own apps, and within them are files, but also folders that I've created that contain other files for that app. I also have created my own folder at the root of my iClouds folder that contains other folders and files for 3rd-party apps and no specific apps at all.
Of course, all those sync with iCloud, which is a handy feature, but it doesn't have to sync with iCloud. If Apple does offer some sort of Xcode option for iOS-based devices, why can't they just have a similar repository for these development files without Apple specifically creating an iOS app called Finder or one called Terminal so I can bypass a reasonable storage selection, look my how Music is stored in the file system, manually edit PLISTs for Library/Preferences and other such things?
What good reason is there to open this up to over a billion iDevice users. Personally, I think how Apple stores photos and music/movies/TV shows in Photos and iTunes, respectively, is the right way to go. Hell, I want Apple to obfuscate this even more in the future so that macOS is even more user friendly, not less.
I wouldn't expect a filesystem to be opened to all iOS devices, just iPad Pros, which would be a few tens of millions of devices but it wouldn't have to be an app, just a core service and file management would be done indirectly. For example, on macOS, when you download files, they go into the Finder somewhere and all files from all apps go there. On iOS, a core service can have a file space per app so if you wanted to save zip files, images, webarchives from Safari, you'd just be able to save them to the app's file space, ideally in collections and it would be much neater and more contained. These files/collections could be shared between apps.
In the example of code, there may be a project on sourceforge that can be downloaded as a .zip. You'd create a collection in Safari, put the .zip in and extract the files. Hop over to XCode for iOS and allow access to that collection and import the files needed from the archive.
When doing something that needs multiple types of media, a file collection can be shared by an image editing app, an audio app, a text editing app etc.
All good points -- except maybe when you suggest that: "On iOS, a core service can have a file space per app". That just sort of made the whole body tighten up - probably because I was indoctrinated into mainframe, enterprise level systems design where a core concept was separation of data from software.
The two were stored separately, never intermixed. So, that enabled a higher level of security in all of its facets (not just from hackers, but it helped to insure the integrity of the data).
The opposite of that is the spreadsheet concept where the software (functions, etc) and the raw data are inextricably intermixed. While that creates some efficiencies and works particularly well in a single user environment, it also creates inherent instabilities where the core data can easily be corrupted with a flick of the finger and protecting the data is particularly difficult.
No, I feel much more comfortable separating software from the data as much as possible... ... My theory is: I can always replace the hardware and software. But not the data Protect the data.
I agree with protecting the data and separation from apps, the system would just be a sandboxed system, not like embedded data. Like how they use containers for Safari Extensions. Access to the iOS containers would be blocked from apps by default for security, unlike in a normal filesystem where any malicious software can erase, encrypt, upload user-level files. Downloads in Safari for example couldn't be accessed by Pages until granted access.
These containers would be separate from the app so that apps could be removed while leaving them in place. They'd be accessible via the core service like the slide-down notifications panel. The benefit of not having it behave like the Finder is that it avoids becoming a dumping ground for files from any app. It makes it easier to navigate and manage when the collections accessible from within an app are the ones relevant to that app. For example, on macOS, you have to go to /Users/<name>/Downloads to get to Safari downloads whereas with app-specific sandboxes, the core service would only show the downloads so it's faster to access and to manage. Safari doesn't need to see the rest of the filesystem by default like it does with the Finder. Pages doesn't need to see Safari downloads by default. They only need to see their own space by default and others when necessary and it means there isn't the same need to tap through lots of folder hierarchies.
It also makes it easier to send files to/from iOS because you could have a sharing system that only accesses a single collection. A movie app can have a collection of clips. Say that footage is on the Mac, the iOS device would be placed nearby, then allow sharing the single collection and it appears on the Mac, have FCPX create proxy files and drop them in the collection. The iOS app now has direct access to all the proxy clips. The iOS app can save an XML edit into the collection, open it on the Mac and it uses the source files for the edit.
You have that well thought out... That makes sense -- even to an old mainframe guy...
Even with the Blueprints option in play this is still not feasible for a device where the primary I/O is your finger on a touchscreen. Are you saying you can switch to only Blueprints as your primary UI without all the other clutter that requires a a finer point on a touch element, as well various L/R or Alt/Option buttons with the mouse pointer to make selections for easy coding?
2) Am I wrong in thinking that Apple already has something similar with Storyboards in Xcode?
Storyboards is an example of this, it generates code in the background while manipulating objects in the UI. I think it would be possible to have a primary UI that was much simpler. The XCode UI has a lot of options visible that are never needed to build an app. A visual UI may not be as efficient for good coders but it would be faster to learn for new developers. That's not to say that a pointer option wouldn't help though, I think trackpad support would work quite well but not a mouse cursor as it is strictly singular input, it needs to be multitouch like circles for finger locations on the pad.
I don't get this incessant need for "access to the file system." Why is that necessary? I have dozens folders synced to iCloud. Many of them are Apple's own apps, and within them are files, but also folders that I've created that contain other files for that app. I also have created my own folder at the root of my iClouds folder that contains other folders and files for 3rd-party apps and no specific apps at all.
Of course, all those sync with iCloud, which is a handy feature, but it doesn't have to sync with iCloud. If Apple does offer some sort of Xcode option for iOS-based devices, why can't they just have a similar repository for these development files without Apple specifically creating an iOS app called Finder or one called Terminal so I can bypass a reasonable storage selection, look my how Music is stored in the file system, manually edit PLISTs for Library/Preferences and other such things?
What good reason is there to open this up to over a billion iDevice users. Personally, I think how Apple stores photos and music/movies/TV shows in Photos and iTunes, respectively, is the right way to go. Hell, I want Apple to obfuscate this even more in the future so that macOS is even more user friendly, not less.
I wouldn't expect a filesystem to be opened to all iOS devices, just iPad Pros, which would be a few tens of millions of devices but it wouldn't have to be an app, just a core service and file management would be done indirectly. For example, on macOS, when you download files, they go into the Finder somewhere and all files from all apps go there. On iOS, a core service can have a file space per app so if you wanted to save zip files, images, webarchives from Safari, you'd just be able to save them to the app's file space, ideally in collections and it would be much neater and more contained. These files/collections could be shared between apps.
In the example of code, there may be a project on sourceforge that can be downloaded as a .zip. You'd create a collection in Safari, put the .zip in and extract the files. Hop over to XCode for iOS and allow access to that collection and import the files needed from the archive.
When doing something that needs multiple types of media, a file collection can be shared by an image editing app, an audio app, a text editing app etc.
All good points -- except maybe when you suggest that: "On iOS, a core service can have a file space per app". That just sort of made the whole body tighten up - probably because I was indoctrinated into mainframe, enterprise level systems design where a core concept was separation of data from software.
The two were stored separately, never intermixed. So, that enabled a higher level of security in all of its facets (not just from hackers, but it helped to insure the integrity of the data).
The opposite of that is the spreadsheet concept where the software (functions, etc) and the raw data are inextricably intermixed. While that creates some efficiencies and works particularly well in a single user environment, it also creates inherent instabilities where the core data can easily be corrupted with a flick of the finger and protecting the data is particularly difficult.
No, I feel much more comfortable separating software from the data as much as possible... ... My theory is: I can always replace the hardware and software. But not the data Protect the data.
I agree with protecting the data and separation from apps, the system would just be a sandboxed system, not like embedded data. Like how they use containers for Safari Extensions. Access to the iOS containers would be blocked from apps by default for security, unlike in a normal filesystem where any malicious software can erase, encrypt, upload user-level files. Downloads in Safari for example couldn't be accessed by Pages until granted access.
These containers would be separate from the app so that apps could be removed while leaving them in place. They'd be accessible via the core service like the slide-down notifications panel. The benefit of not having it behave like the Finder is that it avoids becoming a dumping ground for files from any app. It makes it easier to navigate and manage when the collections accessible from within an app are the ones relevant to that app. For example, on macOS, you have to go to /Users/<name>/Downloads to get to Safari downloads whereas with app-specific sandboxes, the core service would only show the downloads so it's faster to access and to manage. Safari doesn't need to see the rest of the filesystem by default like it does with the Finder. Pages doesn't need to see Safari downloads by default. They only need to see their own space by default and others when necessary and it means there isn't the same need to tap through lots of folder hierarchies.
It also makes it easier to send files to/from iOS because you could have a sharing system that only accesses a single collection. A movie app can have a collection of clips. Say that footage is on the Mac, the iOS device would be placed nearby, then allow sharing the single collection and it appears on the Mac, have FCPX create proxy files and drop them in the collection. The iOS app now has direct access to all the proxy clips. The iOS app can save an XML edit into the collection, open it on the Mac and it uses the source files for the edit.
You have that well thought out... That makes sense -- even to an old mainframe guy…
This is exactly what Apple has been doing with iOS and moving toward with macOS. Isn't that the exact thing you wanted less of?
Even with the Blueprints option in play this is still not feasible for a device where the primary I/O is your finger on a touchscreen. Are you saying you can switch to only Blueprints as your primary UI without all the other clutter that requires a a finer point on a touch element, as well various L/R or Alt/Option buttons with the mouse pointer to make selections for easy coding?
2) Am I wrong in thinking that Apple already has something similar with Storyboards in Xcode?
Storyboards is an example of this, it generates code in the background while manipulating objects in the UI. I think it would be possible to have a primary UI that was much simpler. The XCode UI has a lot of options visible that are never needed to build an app. A visual UI may not be as efficient for good coders but it would be faster to learn for new developers. That's not to say that a pointer option wouldn't help though, I think trackpad support would work quite well but not a mouse cursor as it is strictly singular input, it needs to be multitouch like circles for finger locations on the pad.
I don't get this incessant need for "access to the file system." Why is that necessary? I have dozens folders synced to iCloud. Many of them are Apple's own apps, and within them are files, but also folders that I've created that contain other files for that app. I also have created my own folder at the root of my iClouds folder that contains other folders and files for 3rd-party apps and no specific apps at all.
Of course, all those sync with iCloud, which is a handy feature, but it doesn't have to sync with iCloud. If Apple does offer some sort of Xcode option for iOS-based devices, why can't they just have a similar repository for these development files without Apple specifically creating an iOS app called Finder or one called Terminal so I can bypass a reasonable storage selection, look my how Music is stored in the file system, manually edit PLISTs for Library/Preferences and other such things?
What good reason is there to open this up to over a billion iDevice users. Personally, I think how Apple stores photos and music/movies/TV shows in Photos and iTunes, respectively, is the right way to go. Hell, I want Apple to obfuscate this even more in the future so that macOS is even more user friendly, not less.
I wouldn't expect a filesystem to be opened to all iOS devices, just iPad Pros, which would be a few tens of millions of devices but it wouldn't have to be an app, just a core service and file management would be done indirectly. For example, on macOS, when you download files, they go into the Finder somewhere and all files from all apps go there. On iOS, a core service can have a file space per app so if you wanted to save zip files, images, webarchives from Safari, you'd just be able to save them to the app's file space, ideally in collections and it would be much neater and more contained. These files/collections could be shared between apps.
In the example of code, there may be a project on sourceforge that can be downloaded as a .zip. You'd create a collection in Safari, put the .zip in and extract the files. Hop over to XCode for iOS and allow access to that collection and import the files needed from the archive.
When doing something that needs multiple types of media, a file collection can be shared by an image editing app, an audio app, a text editing app etc.
All good points -- except maybe when you suggest that: "On iOS, a core service can have a file space per app". That just sort of made the whole body tighten up - probably because I was indoctrinated into mainframe, enterprise level systems design where a core concept was separation of data from software.
The two were stored separately, never intermixed. So, that enabled a higher level of security in all of its facets (not just from hackers, but it helped to insure the integrity of the data).
The opposite of that is the spreadsheet concept where the software (functions, etc) and the raw data are inextricably intermixed. While that creates some efficiencies and works particularly well in a single user environment, it also creates inherent instabilities where the core data can easily be corrupted with a flick of the finger and protecting the data is particularly difficult.
No, I feel much more comfortable separating software from the data as much as possible... ... My theory is: I can always replace the hardware and software. But not the data Protect the data.
I agree with protecting the data and separation from apps, the system would just be a sandboxed system, not like embedded data. Like how they use containers for Safari Extensions. Access to the iOS containers would be blocked from apps by default for security, unlike in a normal filesystem where any malicious software can erase, encrypt, upload user-level files. Downloads in Safari for example couldn't be accessed by Pages until granted access.
These containers would be separate from the app so that apps could be removed while leaving them in place. They'd be accessible via the core service like the slide-down notifications panel. The benefit of not having it behave like the Finder is that it avoids becoming a dumping ground for files from any app. It makes it easier to navigate and manage when the collections accessible from within an app are the ones relevant to that app. For example, on macOS, you have to go to /Users/<name>/Downloads to get to Safari downloads whereas with app-specific sandboxes, the core service would only show the downloads so it's faster to access and to manage. Safari doesn't need to see the rest of the filesystem by default like it does with the Finder. Pages doesn't need to see Safari downloads by default. They only need to see their own space by default and others when necessary and it means there isn't the same need to tap through lots of folder hierarchies.
It also makes it easier to send files to/from iOS because you could have a sharing system that only accesses a single collection. A movie app can have a collection of clips. Say that footage is on the Mac, the iOS device would be placed nearby, then allow sharing the single collection and it appears on the Mac, have FCPX create proxy files and drop them in the collection. The iOS app now has direct access to all the proxy clips. The iOS app can save an XML edit into the collection, open it on the Mac and it uses the source files for the edit.
You have that well thought out... That makes sense -- even to an old mainframe guy…
This is exactly what Apple has been doing with iOS and moving toward with macOS. Isn't that the exact thing you wanted less of?
iOS currently puts files inside the app so removing the app removes the files and makes them hard to backup and share. It's also not easy to share files (especially multiple files at once) between apps, you have to send them back and forward manually or rely on iCloud. iCloud isn't bad but its not great when you are mobile and you have big files. Consider adding different media to Keynote like images, audio, video:
If you are building a presentation, having to put images in the Photos app, videos maybe in iMovie or iCloud, audio from Garageband or downloaded from Safari, the files are scattered around. Having them together makes it easier to keep track of them. iCloud works here but with big files, it's much faster to work offline. You don't want to have to be editing video clips or audio, save it up to the cloud then download it again in Keynote, it's easier to have a local file space that is shared between apps.
For productive tasks, having a file management part of iOS that allows these things would be more flexible and brings iOS closer to macOS but it can be limited to iPads/iPad Pros at least at first to see if there are any security issues.
Comments
But it is equally ridiculous to believe that Apple can continue to restrict the functionality of its primary OS for much longer without suffering consequences of falling out of date.
And the "Ideal UI" is not the one that you (or Apple) designate. Neither is it the one that makes the hardware happy. It's the one that makes the user happy. Sometimes that means a touch interface and sometimes that means a mouse and cursor -- it depends on the task, not the hardware.
Furthermore, I can't imagine how much of a nightmare it would be coding with an on-screen keyboard. Code differs quite a bit from just writing text because it is completely unforgiving in the way it must be formatted and uses lots of special characters. I hate using iOS for any lengthy documents. It is so tedious.
I wouldn't expect a filesystem to be opened to all iOS devices, just iPad Pros, which would be a few tens of millions of devices but it wouldn't have to be an app, just a core service and file management would be done indirectly. For example, on macOS, when you download files, they go into the Finder somewhere and all files from all apps go there. On iOS, a core service can have a file space per app so if you wanted to save zip files, images, webarchives from Safari, you'd just be able to save them to the app's file space, ideally in collections and it would be much neater and more contained. These files/collections could be shared between apps.
In the example of code, there may be a project on sourceforge that can be downloaded as a .zip. You'd create a collection in Safari, put the .zip in and extract the files. Hop over to XCode for iOS and allow access to that collection and import the files needed from the archive.
When doing something that needs multiple types of media, a file collection can be shared by an image editing app, an audio app, a text editing app etc.
I love Windows 10 I think it's their greatest OS EVER but it is so far behind macOS that it is a joke to call it a modern OS.
Metro is a great interface but it can be quite jarring using the same interface on a laptop as on a tablet because they use completely different UIs. That's what got Microsoft in trouble with Windows 8 originally because the tiles structure of Metro apps didn't work well on a mouse driven interface.
Apple have stuck with different interfaces for iOS and macOS because they make sense for the platforms. A convergence of the two WILL NOT WORK because we saw this with Windows 8. There is a precedent as to how bad an idea this is. The fact that you haven't learned this yet is kind of negating your comment.
A mobile device that you carry around with you makes sense to use a finger because you simply don't carry a mouse around with you everywhere you go. Most of the places you use a tablet or phone make using a mouse impossible.
A laptop is largely static even though it can be moved around with ease when you use a laptop you literally stay in one spot because it's easier to use that way. You can make a claim for convertibles but let's face it, Microsoft has been promoting them for over 10 years and they've gained zero traction.
Then of course you have a desktop which is completely static. In both the laptop and desktop cases their static nature makes a mouse more useful and allows a greater precision than a finger can and therefore the heavy lifting makes more sense to be offloaded to a desktop or laptop than a mobile device like a tablet or phone.
The "Ideal UI" therefore IS hardware dependant and not user dependant.
And, your proof that a laptop can only ever be a laptop and a tablet can only ever be a tablet is a bit like saying: "A phone can only ever be a phone and a web browser can only browse the web -- they cannot ever be joined".
The two were stored separately, never intermixed. So, that enabled a higher level of security in all of its facets (not just from hackers, but it helped to insure the integrity of the data).
The opposite of that is the spreadsheet concept where the software (functions, etc) and the raw data are inextricably intermixed. While that creates some efficiencies and works particularly well in a single user environment, it also creates inherent instabilities where the core data can easily be corrupted with a flick of the finger and protecting the data is particularly difficult.
No, I feel much more comfortable separating software from the data as much as possible...
... My theory is: I can always replace the hardware and software. But not the data Protect the data.
These containers would be separate from the app so that apps could be removed while leaving them in place. They'd be accessible via the core service like the slide-down notifications panel. The benefit of not having it behave like the Finder is that it avoids becoming a dumping ground for files from any app. It makes it easier to navigate and manage when the collections accessible from within an app are the ones relevant to that app. For example, on macOS, you have to go to /Users/<name>/Downloads to get to Safari downloads whereas with app-specific sandboxes, the core service would only show the downloads so it's faster to access and to manage. Safari doesn't need to see the rest of the filesystem by default like it does with the Finder. Pages doesn't need to see Safari downloads by default. They only need to see their own space by default and others when necessary and it means there isn't the same need to tap through lots of folder hierarchies.
It also makes it easier to send files to/from iOS because you could have a sharing system that only accesses a single collection. A movie app can have a collection of clips. Say that footage is on the Mac, the iOS device would be placed nearby, then allow sharing the single collection and it appears on the Mac, have FCPX create proxy files and drop them in the collection. The iOS app now has direct access to all the proxy clips. The iOS app can save an XML edit into the collection, open it on the Mac and it uses the source files for the edit.
https://support.apple.com/kb/PH24106
If you are building a presentation, having to put images in the Photos app, videos maybe in iMovie or iCloud, audio from Garageband or downloaded from Safari, the files are scattered around. Having them together makes it easier to keep track of them. iCloud works here but with big files, it's much faster to work offline. You don't want to have to be editing video clips or audio, save it up to the cloud then download it again in Keynote, it's easier to have a local file space that is shared between apps.
For productive tasks, having a file management part of iOS that allows these things would be more flexible and brings iOS closer to macOS but it can be limited to iPads/iPad Pros at least at first to see if there are any security issues.