iOS needs a MAJOR overhaul with the focus on usability. Apple needs to follow its own design guidelines across the whole system and focus on making things uniform. Text selection and input needs work and folder navigation would be nice.
It would be nice if iDevices belonging to the same user could be used as toolbox or pallette holders for applications on other devices. For example, if I am using Pages on an iPad I would like to have options from the app displayed on my phone screen. It would be even better if the same functionality could be built into macOS and have Mac Pages options available on an iDevice.
Hey, I'd like it as well but folder navigation is not something they didn't know how to code. It was purposely left out of the iOS experience. So it is not likely to appear any time soon and it would seem they made the right choice, given thei success and the incredible powerful things you can do with iOS devices.
iOS does not need MAJOR overhaul. It needs thoughtful, steady improvements as they've always done. MAJOR overhauls is what lesser companies try and do for a quick catch of the market's attention. Just look at car brands. You either follow your course plotted long ago and make small course corrections or keep wandering in a different direction at each try. Not a successful strategy.
Mac apps integration with iOS has little value. Maybe you'd enjoy it but pursuing it wouldn't be a good allocation of resources. Most people wouldnt use it and it's redundant. It is why you have the touch bar in MacBook and soon in desktop form.
iOS and the devices it runs on have changed enormously over the years. We have had plenty of time for thoughtful steady change. It hasn't happened in userland. We got redesigns of the interface and doors bolted shut.
Jonny Ive's contribution wasn't helpful at all as the changes were made to look good. Not be good. That's why to close a Safari tab without changing the UI screen on a Mini, the UI element you are required to hit measures approximately 4mm in diameter. iOS is literally plagued with UI design flaws. Text selection, options and manipulation need some serious work.
You can send any document from a Mac to any device that supports Bluetooth file transfer. No one has ever been able to explain why that particular door was permanently bolted shut on iDevices. AirDrop, the supposed (Apple only) solution, stupidly requires not only Bluetooth but WiFi and iCloud and is plagued with issues.
Yes, the system was designed specifically to exclude file navigation but that was a long time ago. Times have changed. We now create far more documents than before on iDevices and folder navigation would be a welcome addition.
Just switch on any iDevice for the first time and go to settings. It is a mess with options spread all over the place. Clearly nobody foresaw that the settings panel might require so many options down the line.
Sending documents between apps has always been a hassle. Something simple like adding an attachment to a mail was a hoop jumping exercise.
Shake to undo has to be one of the most unintuitive things I've seen. Loading the classic version of a web site is just as unintuitive. Opening a mail draft. Etc
It would be nice if iDevices belonging to the same user could be used as toolbox or pallette holders for applications on other devices. For example, if I am using Pages on an iPad I would like to have options from the app displayed on my phone screen. It would be even better if the same functionality could be built into macOS and have Mac Pages options available on an iDevice.
Having your phone display palettes and options for your iPad apps is such an outlier use case and so far in the opposite direction of "simplicity" that it's mad even to ask for it. You're just not in apple's target audience or you simply dont get what Apple is trying to do and why it's better than over-techie options like Android or Windows. There's a reason my parents don't use or understand PCs but take instantly to iPads. Simplicity.
The guaranteed new stuff out of WWDC will be software related. iOS, watchOS, tvOS, macOS. Anything hardware related would be a bonus. Siri speaker, new 10.5" iPad MacBooks etc.
What I am really hoping for, 1) iPad specific changes to iOS to make it more versatile. Stuff like drag and drop e-mail attachments. Not likely to get mouse support and I'm OK with that. 2) Expand the free tier of iCloud storage to something greater than 5GB, or have photo storage, iCloud backups and macOS desktop not deducted from that 5GB. This limit is pushing many iPhone users to store their photos with Google's services. Apple should bring those users back.. 3) Split iTunes into Apple Music app, Podcast app, iDevice backup app, movie/TV show app. 4) Allow iPhone users to unlock their Mac like Apple watch users can. Some of us simply do not need or want to wear any watch. BTW, I love the MacID app that does that but doesn't always work or sometimes I have to wait several seconds before it activates on my iPhone.
They need to add mouse support to iOS on the iPad and the next step is releasing an iOSBook Laptop.
The exact same thing was said when Netbooks were the “iPad killers” du jour. Remember? The current iPad killer is the Surface du jour. Before cajoling Apple into something try it out on another platform first. I think Apple made its decisions about what the iPad would be years ago and they show absolutely no sign of abandoning those decisions. Maybe we should be asking for something that could actually happen.
It would be nice if iDevices belonging to the same user could be used as toolbox or pallette holders for applications on other devices. For example, if I am using Pages on an iPad I would like to have options from the app displayed on my phone screen. It would be even better if the same functionality could be built into macOS and have Mac Pages options available on an iDevice.
Having your phone display palettes and options for your iPad apps is such an outlier use case and so far in the opposite direction of "simplicity" that it's mad even to ask for it. You're just not in apple's target audience or you simply dont get what Apple is trying to do and why it's better than over-techie options like Android or Windows. There's a reason my parents don't use or understand PCs but take instantly to iPads. Simplicity.
Simplicity?
iOS is maddeningly full of multiple personalities. Haven't you ever watched people blindly swipe up, down, left and right, press UI elements because they think they might do something, use finger gestures without knowing exactly which ones to use? Search blindly for simple ways to do simple things?
More often than not, trying to undo things they did unwittingly in the first place!
Undo is simple. Shame it is completely undiscoverable. Something that is one of the pillars of interface design.
No. Simplicity doesn't apply to iOS today. That went out the window years ago.
This may seem a bit petty, but can Apple just please fix their gd keyboard predictions. I've never in my life wanted to write "haga" or "Gaga" or "jags". But even though I've written "haha" thousands of times, Apple still wants to try those other corrections. When it thinks I want "haha," it decides to suggest "Hahahaha" instead which, needless to say, is way too many "haha"'s. How does this not annoy the hell out of Apple employees. I figured this would be fixed years ago.
It's simple things like this that are so frustrating. Like how if siri presents a list, you can't say, "the second one." Instead you need to repeat your original request, which siri got wrong in the first place, so why would you repeat it and risk siri presenting a list again?
Or if I'm trying to control homekit, I can't say "turn my kitchen and living room lights to 50%." Siri gets confused and I have to say each one separately.
How does Apple not catch this simple stuff with dogfooding?
The same thing every year. All the experts (idiots) telling us how Apple screwed up and didn't add the features "THEY" think are required and are a dealbreaker for them to consider buying an iOS device. Followed by the fandroids proclaiming they had those features first and Apple is catching up to 2010. And so on.
In short, WWDC is the Apple haters worst nightmare.
I'm really bummed out with IOS on iPad and would love to see signs that they are becoming more open and supportive on the platform. I look at it this way, I prefer to have my cell phone locked down hard as reliability is very important. However that same tight control of the device is a big negative on iPad so I'd like to see Apple change its ways here. I'm especially interested in port access that doesn't require special hardware to achieve. The reason here is pretty simple, iPads could easily be recycled into stand alone terminals to communicate tight things like CNC controllers, automation projects or simply projects an an Arduino.
As for Mac OS well that has become my daily way to access the internet (iPad is broken and iPhone is way too slow). So the obvious thing here is that we see Apple going in the right direction with Safari, maintaining standards compatibility and speed. Xcode on Mac OS could use an overhaul, I'm thinking a rewrite in Swift with the hope that they kill a lot of bugs by doing so. Oh speaking of rewrites, ITunes is a mess!
Yep we need padOS to really allow the iPad to push the function that suits the screen size and possible interaction of macOS and padOS. Yep iTunes needs to die and get back to just being a music player. I think the rest of the function that has been grafted on belongs elsewhere maybe even iCloud.
You can send any document from a Mac to any device that supports Bluetooth file transfer. No one has ever been able to explain why that particular door was permanently bolted shut on iDevices.
Yes, the system was designed specifically to exclude file navigation but that was a long time ago. Times have changed. We now create far more documents than before on iDevices and folder navigation would be a welcome addition.
Just switch on any iDevice for the first time and go to settings. It is a mess with options spread all over the place. Clearly nobody foresaw that the settings panel might require so many options down the line.
The explanation for shutting Bluetooth transfer is simple. Precisely because users have more media than ever, it's a way to impede major piracy. If you notice, not even Android supports it fully anymore, at least not all of them. Companies with skin in the game have been closing the doors as they enter the parallel media selling market.
As for folder navigation, I believe it's the way they intended it to be. They took a lot of time and pride building apps that are far easier to use for their specific purpose. Want music? Music app. Want books? Books app. Photos? Photos app. They are moving away from the filesystem and improving the shortcomings with spotlight and AI. That's the way it is. I happen to appreciate it.
It is nice to have but not remotely as useful as in a desktop or laptop. If they don't get to introduce that, you always have Android. You will find Android settings being way messier.
iOS isn't without its faults. There is no perfection, you just have to find which imperfections you can live best with.
What To Expect From WWDC 2017? Answer: a shit ton of upset "journalist."
Who were expecting the next Messiah and came away with an empty wine bottle (no water).
honestly, if you go to an event like this and expect to be blown away with the tech on show then this is clearly the wrong event for you. Perhaps a comecom or something might be appropriate. Maybe it is the fact that I've attended (and exhibited) tech conferences all over the planet in the last 40 years and only once did I have my mind blown away. That was a Telecoms '87 in Geneva where I saw Sony HD TV for the first time. They had a camera pointing at a Geisha doll. next to it was a monitor where you could see the doll. You could compare the TV picture and the real thing side by side. The remainder of them where very much 'Meh' events when it came to the tech. Some of the plenary sessions are good though.
Only thing that ever blew me away was the iPhone unveiling. And I expected that to be real good.
I'm really bummed out with IOS on iPad and would love to see signs that they are becoming more open and supportive on the platform. I look at it this way, I prefer to have my cell phone locked down hard as reliability is very important. However that same tight control of the device is a big negative on iPad so I'd like to see Apple change its ways here. I'm especially interested in port access that doesn't require special hardware to achieve. The reason here is pretty simple, iPads could easily be recycled into stand alone terminals to communicate tight things like CNC controllers, automation projects or simply projects an an Arduino.
As for Mac OS well that has become my daily way to access the internet (iPad is broken and iPhone is way too slow). So the obvious thing here is that we see Apple going in the right direction with Safari, maintaining standards compatibility and speed. Xcode on Mac OS could use an overhaul, I'm thinking a rewrite in Swift with the hope that they kill a lot of bugs by doing so. Oh speaking of rewrites, ITunes is a mess!
I agree with all of this, especially iOS and the iPad Pro.
IMO, iOS on the iPad should address [at least] 2 levels of users: the current consumer level; the pro level.
For example, in education, the Swift Playgrounds iPad app is an excellent vehicle to introduce coding to the masses (consumers). But to go to the pro level, where the user (developer) is actually writing, testing, maintaining production code -- you need to run Xcode on the iPad -- along with access to the file system, separate kb/cursor, etc. Apple's HandOff capability would be a real boon as it would allow you to pickup and go, taking your code and IDE with you.
Yeah, and why not enhance iOS to allow the iPad to act as an ad hoc display/kb/trackpad UI for headless computers such as Mac Minis, servers, etc.
I'm really bummed out with IOS on iPad and would love to see signs that they are becoming more open and supportive on the platform. I look at it this way, I prefer to have my cell phone locked down hard as reliability is very important. However that same tight control of the device is a big negative on iPad so I'd like to see Apple change its ways here. I'm especially interested in port access that doesn't require special hardware to achieve. The reason here is pretty simple, iPads could easily be recycled into stand alone terminals to communicate tight things like CNC controllers, automation projects or simply projects an an Arduino.
As for Mac OS well that has become my daily way to access the internet (iPad is broken and iPhone is way too slow). So the obvious thing here is that we see Apple going in the right direction with Safari, maintaining standards compatibility and speed. Xcode on Mac OS could use an overhaul, I'm thinking a rewrite in Swift with the hope that they kill a lot of bugs by doing so. Oh speaking of rewrites, ITunes is a mess!
I agree with all of this, especially iOS and the iPad Pro.
IMO, iOS on the iPad should address [at least] 2 levels of users: the current consumer level; the pro level.
For example, in education, the Swift Playgrounds iPad app is an excellent vehicle to introduce coding to the masses (consumers). But to go to the pro level, where the user (developer) is actually writing, testing, maintaining production code -- you need to run Xcode on the iPad -- along with access to the file system, separate kb/cursor, etc. Apple's HandOff capability would be a real boon as it would allow you to pickup and go, taking your code and IDE with you.
Yeah, and why not enhance iOS to allow the iPad to act as an ad hoc display/kb/trackpad UI for headless computers such as Mac Minis, servers, etc.
Why do you need access to the OS's file system to build an app?
You can send any document from a Mac to any device that supports Bluetooth file transfer. No one has ever been able to explain why that particular door was permanently bolted shut on iDevices.
Yes, the system was designed specifically to exclude file navigation but that was a long time ago. Times have changed. We now create far more documents than before on iDevices and folder navigation would be a welcome addition.
Just switch on any iDevice for the first time and go to settings. It is a mess with options spread all over the place. Clearly nobody foresaw that the settings panel might require so many options down the line.
The explanation for shutting Bluetooth transfer is simple. Precisely because users have more media than ever, it's a way to impede major piracy. If you notice, not even Android supports it fully anymore, at least not all of them. Companies with skin in the game have been closing the doors as they enter the parallel media selling market.
As for folder navigation, I believe it's the way they intended it to be. They took a lot of time and pride building apps that are far easier to use for their specific purpose. Want music? Music app. Want books? Books app. Photos? Photos app. They are moving away from the filesystem and improving the shortcomings with spotlight and AI. That's the way it is. I happen to appreciate it.
It is nice to have but not remotely as useful as in a desktop or laptop. If they don't get to introduce that, you always have Android. You will find Android settings being way messier.
iOS isn't without its faults. There is no perfection, you just have to find which imperfections you can live best with.
We've already been down the DRM road and it largely failed. So much that many countries have laws for digital copies for personal use and a surcharge is applied to all devices with writable memory even if you don't make copies of any media. Trying to directly impede illegal file transfer will ultimately fail. It always has.
The no direct transfer decision also runs into another problem. They take functionality away on the grounds that you might do something illegal with it (piracy). Of course, that is not Apple's or anybody's judgement to make on the users' behalf and makes little sense when what you want to do is simply transfer the photos you have just taken, directly to your friend's phone.
I was unaware that some Android phones lack the file transfer profile.
I'm really bummed out with IOS on iPad and would love to see signs that they are becoming more open and supportive on the platform. I look at it this way, I prefer to have my cell phone locked down hard as reliability is very important. However that same tight control of the device is a big negative on iPad so I'd like to see Apple change its ways here. I'm especially interested in port access that doesn't require special hardware to achieve. The reason here is pretty simple, iPads could easily be recycled into stand alone terminals to communicate tight things like CNC controllers, automation projects or simply projects an an Arduino.
As for Mac OS well that has become my daily way to access the internet (iPad is broken and iPhone is way too slow). So the obvious thing here is that we see Apple going in the right direction with Safari, maintaining standards compatibility and speed. Xcode on Mac OS could use an overhaul, I'm thinking a rewrite in Swift with the hope that they kill a lot of bugs by doing so. Oh speaking of rewrites, ITunes is a mess!
I agree with all of this, especially iOS and the iPad Pro.
IMO, iOS on the iPad should address [at least] 2 levels of users: the current consumer level; the pro level.
For example, in education, the Swift Playgrounds iPad app is an excellent vehicle to introduce coding to the masses (consumers). But to go to the pro level, where the user (developer) is actually writing, testing, maintaining production code -- you need to run Xcode on the iPad -- along with access to the file system, separate kb/cursor, etc. Apple's HandOff capability would be a real boon as it would allow you to pickup and go, taking your code and IDE with you.
Yeah, and why not enhance iOS to allow the iPad to act as an ad hoc display/kb/trackpad UI for headless computers such as Mac Minis, servers, etc.
Why do you need access to the OS's file system to build an app?
Because a typical app, whether iOS, tvOS, watchOS or macOS, requires lotsa' lotsa' files -- and you need to manipulate them.
Below is an email I just received from Swift@IBM.com for a simple app to send emails:
If you do the first 3 steps:
download the project from Github
run swift package generate-xcodeproj
open the generated Xcode project
You will get hundreds of files (web server, SMTP server, logger, etc.) and thousands of lines of code:
I'm really bummed out with IOS on iPad and would love to see signs that they are becoming more open and supportive on the platform. I look at it this way, I prefer to have my cell phone locked down hard as reliability is very important. However that same tight control of the device is a big negative on iPad so I'd like to see Apple change its ways here. I'm especially interested in port access that doesn't require special hardware to achieve. The reason here is pretty simple, iPads could easily be recycled into stand alone terminals to communicate tight things like CNC controllers, automation projects or simply projects an an Arduino.
As for Mac OS well that has become my daily way to access the internet (iPad is broken and iPhone is way too slow). So the obvious thing here is that we see Apple going in the right direction with Safari, maintaining standards compatibility and speed. Xcode on Mac OS could use an overhaul, I'm thinking a rewrite in Swift with the hope that they kill a lot of bugs by doing so. Oh speaking of rewrites, ITunes is a mess!
I agree with all of this, especially iOS and the iPad Pro.
IMO, iOS on the iPad should address [at least] 2 levels of users: the current consumer level; the pro level.
For example, in education, the Swift Playgrounds iPad app is an excellent vehicle to introduce coding to the masses (consumers). But to go to the pro level, where the user (developer) is actually writing, testing, maintaining production code -- you need to run Xcode on the iPad -- along with access to the file system, separate kb/cursor, etc. Apple's HandOff capability would be a real boon as it would allow you to pickup and go, taking your code and IDE with you.
Yeah, and why not enhance iOS to allow the iPad to act as an ad hoc display/kb/trackpad UI for headless computers such as Mac Minis, servers, etc.
Why do you need access to the OS's file system to build an app?
Because a typical app, whether iOS, tvOS, watchOS or macOS, requires lotsa' lotsa' files -- and you need to manipulate them.
Below is an email I just received from Swift@IBM.com for a simple app to send emails:
If you do the first 3 steps:
download the project from Github
run swift package generate-xcodeproj
open the generated Xcode project
You will get hundreds of files (web server, SMTP server, logger, etc.) and thousands of lines of code:
You see that list of files on the left? That's not your OS's file system, that's Xcode showing you a list of files. You don't need access to `/usr/bin` and other areas of the OS to create a hierarchy of files and folders—this can be down just like the iCloud Drive app on your iOS-based device.
I'm really bummed out with IOS on iPad and would love to see signs that they are becoming more open and supportive on the platform. I look at it this way, I prefer to have my cell phone locked down hard as reliability is very important. However that same tight control of the device is a big negative on iPad so I'd like to see Apple change its ways here. I'm especially interested in port access that doesn't require special hardware to achieve. The reason here is pretty simple, iPads could easily be recycled into stand alone terminals to communicate tight things like CNC controllers, automation projects or simply projects an an Arduino.
As for Mac OS well that has become my daily way to access the internet (iPad is broken and iPhone is way too slow). So the obvious thing here is that we see Apple going in the right direction with Safari, maintaining standards compatibility and speed. Xcode on Mac OS could use an overhaul, I'm thinking a rewrite in Swift with the hope that they kill a lot of bugs by doing so. Oh speaking of rewrites, ITunes is a mess!
I agree with all of this, especially iOS and the iPad Pro.
IMO, iOS on the iPad should address [at least] 2 levels of users: the current consumer level; the pro level.
For example, in education, the Swift Playgrounds iPad app is an excellent vehicle to introduce coding to the masses (consumers). But to go to the pro level, where the user (developer) is actually writing, testing, maintaining production code -- you need to run Xcode on the iPad -- along with access to the file system, separate kb/cursor, etc. Apple's HandOff capability would be a real boon as it would allow you to pickup and go, taking your code and IDE with you.
Yeah, and why not enhance iOS to allow the iPad to act as an ad hoc display/kb/trackpad UI for headless computers such as Mac Minis, servers, etc.
Why do you need access to the OS's file system to build an app?
Because a typical app, whether iOS, tvOS, watchOS or macOS, requires lotsa' lotsa' files -- and you need to manipulate them.
Below is an email I just received from Swift@IBM.com for a simple app to send emails:
If you do the first 3 steps:
download the project from Github
run swift package generate-xcodeproj
open the generated Xcode project
You will get hundreds of files (web server, SMTP server, logger, etc.) and thousands of lines of code:
You see that list of files on the left? That's not your OS's file system, that's Xcode showing you a list of files. You don't need access to `/usr/bin` and other areas of the OS to create a hierarchy of files and folders—this can be down just like the iCloud Drive app on your iOS-based device.
Ahh... But, in order to get to that point (accessing the Xcode project and its associated files) you first need to:
download them to somewhere (the file system)
access the downloaded file structure to generate the Xcode project
I suppose, you could use a dumbed-down file system ala iOS Pages or iOS Swift Playgrounds -- but that would introduce inconsistencies/confusion between macOS use of Xcode and iOS use of Xcode.
The whole thrust of Swift@IBM is to allow you to write/test/debug/maintain both the client-side and server-side locally -- before deployment. It is extremely productive to observe both sides of the application at once -- for debugging and implementing changes. The simple mail app involves a web server and an SMTP server -- it could easily involve separate database servers, several IBM Watson servers (translation, analytics, voice to text, etc.).
Here's how the app looks running both ends locally:
I'm really bummed out with IOS on iPad and would love to see signs that they are becoming more open and supportive on the platform. I look at it this way, I prefer to have my cell phone locked down hard as reliability is very important. However that same tight control of the device is a big negative on iPad so I'd like to see Apple change its ways here. I'm especially interested in port access that doesn't require special hardware to achieve. The reason here is pretty simple, iPads could easily be recycled into stand alone terminals to communicate tight things like CNC controllers, automation projects or simply projects an an Arduino.
As for Mac OS well that has become my daily way to access the internet (iPad is broken and iPhone is way too slow). So the obvious thing here is that we see Apple going in the right direction with Safari, maintaining standards compatibility and speed. Xcode on Mac OS could use an overhaul, I'm thinking a rewrite in Swift with the hope that they kill a lot of bugs by doing so. Oh speaking of rewrites, ITunes is a mess!
I agree with all of this, especially iOS and the iPad Pro.
IMO, iOS on the iPad should address [at least] 2 levels of users: the current consumer level; the pro level.
For example, in education, the Swift Playgrounds iPad app is an excellent vehicle to introduce coding to the masses (consumers). But to go to the pro level, where the user (developer) is actually writing, testing, maintaining production code -- you need to run Xcode on the iPad -- along with access to the file system, separate kb/cursor, etc. Apple's HandOff capability would be a real boon as it would allow you to pickup and go, taking your code and IDE with you.
Yeah, and why not enhance iOS to allow the iPad to act as an ad hoc display/kb/trackpad UI for headless computers such as Mac Minis, servers, etc.
Why do you need access to the OS's file system to build an app?
Because a typical app, whether iOS, tvOS, watchOS or macOS, requires lotsa' lotsa' files -- and you need to manipulate them.
Below is an email I just received from Swift@IBM.com for a simple app to send emails:
If you do the first 3 steps:
download the project from Github
run swift package generate-xcodeproj
open the generated Xcode project
You will get hundreds of files (web server, SMTP server, logger, etc.) and thousands of lines of code:
You see that list of files on the left? That's not your OS's file system, that's Xcode showing you a list of files. You don't need access to `/usr/bin` and other areas of the OS to create a hierarchy of files and folders—this can be down just like the iCloud Drive app on your iOS-based device.
Ahh... But, in order to get to that point (accessing the Xcode project and its associated files) you first need to:
download them to somewhere (the file system)
access the downloaded file structure to generate the Xcode project
I suppose, you could use a dumbed-down file system ala iOS Pages or iOS Swift Playgrounds -- but that would introduce inconsistencies/confusion between macOS use of Xcode and iOS use of Xcode.
The whole thrust of Swift@IBM is to allow you to write/test/debug/maintain both the client-side and server-side locally -- before deployment. It is extremely productive to observe both sides of the application at once -- for debugging and implementing changes. The simple mail app involves a web server and an SMTP server -- it could easily involve separate database servers, several IBM Watson servers (translation, analytics, voice to text, etc.).
Here's how the app looks running both ends locally:
[image]
1) All apps have had the ability to store files to somewhere since day one. None of this would be possible if this wasn't the case.
2) All apps have access to any file structure they wish to offer the user. This is why, for example, Finder, by default, hides certain files and folders; yet, it's still an archaic system on macOS users shouldn't have to deal with and that's not required for an app like Xcode that can access a hierarchal file system from within its own app. Same goes for the Dropbox app on iOS.
3) What you need to figure out is how the Mac version of Xcode could possible work with your fingertips as the primary input on a 4" to 13" display when it's hard enough to use the app on a 13" MBP with a mouse pointer and physical keyboard for input, not wonder how Apple will do something that it already does.
I'm really bummed out with IOS on iPad and would love to see signs that they are becoming more open and supportive on the platform. I look at it this way, I prefer to have my cell phone locked down hard as reliability is very important. However that same tight control of the device is a big negative on iPad so I'd like to see Apple change its ways here. I'm especially interested in port access that doesn't require special hardware to achieve. The reason here is pretty simple, iPads could easily be recycled into stand alone terminals to communicate tight things like CNC controllers, automation projects or simply projects an an Arduino.
As for Mac OS well that has become my daily way to access the internet (iPad is broken and iPhone is way too slow). So the obvious thing here is that we see Apple going in the right direction with Safari, maintaining standards compatibility and speed. Xcode on Mac OS could use an overhaul, I'm thinking a rewrite in Swift with the hope that they kill a lot of bugs by doing so. Oh speaking of rewrites, ITunes is a mess!
I agree with all of this, especially iOS and the iPad Pro.
IMO, iOS on the iPad should address [at least] 2 levels of users: the current consumer level; the pro level.
For example, in education, the Swift Playgrounds iPad app is an excellent vehicle to introduce coding to the masses (consumers). But to go to the pro level, where the user (developer) is actually writing, testing, maintaining production code -- you need to run Xcode on the iPad -- along with access to the file system, separate kb/cursor, etc. Apple's HandOff capability would be a real boon as it would allow you to pickup and go, taking your code and IDE with you.
Yeah, and why not enhance iOS to allow the iPad to act as an ad hoc display/kb/trackpad UI for headless computers such as Mac Minis, servers, etc.
Why do you need access to the OS's file system to build an app?
Because a typical app, whether iOS, tvOS, watchOS or macOS, requires lotsa' lotsa' files -- and you need to manipulate them.
Below is an email I just received from Swift@IBM.com for a simple app to send emails:
If you do the first 3 steps:
download the project from Github
run swift package generate-xcodeproj
open the generated Xcode project
You will get hundreds of files (web server, SMTP server, logger, etc.) and thousands of lines of code:
You see that list of files on the left? That's not your OS's file system, that's Xcode showing you a list of files. You don't need access to `/usr/bin` and other areas of the OS to create a hierarchy of files and folders—this can be down just like the iCloud Drive app on your iOS-based device.
Ahh... But, in order to get to that point (accessing the Xcode project and its associated files) you first need to:
download them to somewhere (the file system)
access the downloaded file structure to generate the Xcode project
I suppose, you could use a dumbed-down file system ala iOS Pages or iOS Swift Playgrounds -- but that would introduce inconsistencies/confusion between macOS use of Xcode and iOS use of Xcode.
The whole thrust of Swift@IBM is to allow you to write/test/debug/maintain both the client-side and server-side locally -- before deployment. It is extremely productive to observe both sides of the application at once -- for debugging and implementing changes. The simple mail app involves a web server and an SMTP server -- it could easily involve separate database servers, several IBM Watson servers (translation, analytics, voice to text, etc.).
Here's how the app looks running both ends locally:
[image]
1) All apps have had the ability to store files to somewhere since day one. None of this would be possible if this wasn't the case.
2) All apps have access to any file structure they wish to offer the user. This is why, for example, Finder, by default, hides certain files and folders; yet, it's still an archaic system on macOS users shouldn't have to deal with and that's not required for an app like Xcode that can access a hierarchal file system from within its own app. Same goes for the Dropbox app on iOS.
3) What you need to figure out is how the Mac version of Xcode could possible work with your fingertips as the primary input on a 4" to 13" display when it's hard enough to use the app on a 13" MBP with a mouse pointer and physical keyboard for input, not wonder how Apple will do something that it already does.
Easy! Add a track pad to the iPad Pro KB/Case and a cursor on the display. This is for pro iPad Pro users. I wouldn't attempt to do this using fingertips with an on-screen KB that takes up 1/2 the screen.
I suspect that IBM is pressuring Apple to provide this kind of [iOS-macOS] 'tweener capability for itself and for its IT customers writing/using/extending IBM's MobileFirst apps.
I'm really bummed out with IOS on iPad and would love to see signs that they are becoming more open and supportive on the platform. I look at it this way, I prefer to have my cell phone locked down hard as reliability is very important. However that same tight control of the device is a big negative on iPad so I'd like to see Apple change its ways here. I'm especially interested in port access that doesn't require special hardware to achieve. The reason here is pretty simple, iPads could easily be recycled into stand alone terminals to communicate tight things like CNC controllers, automation projects or simply projects an an Arduino.
As for Mac OS well that has become my daily way to access the internet (iPad is broken and iPhone is way too slow). So the obvious thing here is that we see Apple going in the right direction with Safari, maintaining standards compatibility and speed. Xcode on Mac OS could use an overhaul, I'm thinking a rewrite in Swift with the hope that they kill a lot of bugs by doing so. Oh speaking of rewrites, ITunes is a mess!
I agree with all of this, especially iOS and the iPad Pro.
IMO, iOS on the iPad should address [at least] 2 levels of users: the current consumer level; the pro level.
For example, in education, the Swift Playgrounds iPad app is an excellent vehicle to introduce coding to the masses (consumers). But to go to the pro level, where the user (developer) is actually writing, testing, maintaining production code -- you need to run Xcode on the iPad -- along with access to the file system, separate kb/cursor, etc. Apple's HandOff capability would be a real boon as it would allow you to pickup and go, taking your code and IDE with you.
Yeah, and why not enhance iOS to allow the iPad to act as an ad hoc display/kb/trackpad UI for headless computers such as Mac Minis, servers, etc.
Why do you need access to the OS's file system to build an app?
Because a typical app, whether iOS, tvOS, watchOS or macOS, requires lotsa' lotsa' files -- and you need to manipulate them.
Below is an email I just received from Swift@IBM.com for a simple app to send emails:
If you do the first 3 steps:
download the project from Github
run swift package generate-xcodeproj
open the generated Xcode project
You will get hundreds of files (web server, SMTP server, logger, etc.) and thousands of lines of code:
You see that list of files on the left? That's not your OS's file system, that's Xcode showing you a list of files. You don't need access to `/usr/bin` and other areas of the OS to create a hierarchy of files and folders—this can be down just like the iCloud Drive app on your iOS-based device.
Ahh... But, in order to get to that point (accessing the Xcode project and its associated files) you first need to:
download them to somewhere (the file system)
access the downloaded file structure to generate the Xcode project
I suppose, you could use a dumbed-down file system ala iOS Pages or iOS Swift Playgrounds -- but that would introduce inconsistencies/confusion between macOS use of Xcode and iOS use of Xcode.
The whole thrust of Swift@IBM is to allow you to write/test/debug/maintain both the client-side and server-side locally -- before deployment. It is extremely productive to observe both sides of the application at once -- for debugging and implementing changes. The simple mail app involves a web server and an SMTP server -- it could easily involve separate database servers, several IBM Watson servers (translation, analytics, voice to text, etc.).
Here's how the app looks running both ends locally:
[image]
1) All apps have had the ability to store files to somewhere since day one. None of this would be possible if this wasn't the case.
2) All apps have access to any file structure they wish to offer the user. This is why, for example, Finder, by default, hides certain files and folders; yet, it's still an archaic system on macOS users shouldn't have to deal with and that's not required for an app like Xcode that can access a hierarchal file system from within its own app. Same goes for the Dropbox app on iOS.
3) What you need to figure out is how the Mac version of Xcode could possible work with your fingertips as the primary input on a 4" to 13" display when it's hard enough to use the app on a 13" MBP with a mouse pointer and physical keyboard for input, not wonder how Apple will do something that it already does.
Easy! Add a track pad to the iPad Pro KB/Case and a cursor on the display. This is for pro iPad Pro users. I wouldn't attempt to do this using fingertips with an on-screen KB that takes up 1/2 the screen.
I suspect that IBM is pressuring Apple to provide this kind of [iOS-macOS] 'tweener capability for itself and for its IT customers writing/using/extending IBM's MobileFirst apps.
This is why you have laptops and desktops. Gotta pick the right tool for the job.
Comments
Jonny Ive's contribution wasn't helpful at all as the changes were made to look good. Not be good. That's why to close a Safari tab without changing the UI screen on a Mini, the UI element you are required to hit measures approximately 4mm in diameter. iOS is literally plagued with UI design flaws. Text selection, options and manipulation need some serious work.
You can send any document from a Mac to any device that supports Bluetooth file transfer. No one has ever been able to explain why that particular door was permanently bolted shut on iDevices. AirDrop, the supposed (Apple only) solution, stupidly requires not only Bluetooth but WiFi and iCloud and is plagued with issues.
Yes, the system was designed specifically to exclude file navigation but that was a long time ago. Times have changed. We now create far more documents than before on iDevices and folder navigation would be a welcome addition.
Just switch on any iDevice for the first time and go to settings. It is a mess with options spread all over the place. Clearly nobody foresaw that the settings panel might require so many options down the line.
Sending documents between apps has always been a hassle. Something simple like adding an attachment to a mail was a hoop jumping exercise.
Shake to undo has to be one of the most unintuitive things I've seen. Loading the classic version of a web site is just as unintuitive. Opening a mail draft. Etc
The list is almost endless.
http://consomac.fr/news-6702-de-nouveaux-macs-et-ipad-en-juin.html
(Google Translate is your friend)
Anything hardware related would be a bonus. Siri speaker, new 10.5" iPad MacBooks etc.
What I am really hoping for,
1) iPad specific changes to iOS to make it more versatile. Stuff like drag and drop e-mail attachments. Not likely to get mouse support and I'm OK with that.
2) Expand the free tier of iCloud storage to something greater than 5GB, or have photo storage, iCloud backups and macOS desktop not deducted from that 5GB. This limit is pushing many iPhone users to store their photos with Google's services. Apple should bring those users back..
3) Split iTunes into Apple Music app, Podcast app, iDevice backup app, movie/TV show app.
4) Allow iPhone users to unlock their Mac like Apple watch users can. Some of us simply do not need or want to wear any watch. BTW, I love the MacID app that does that but doesn't always work or sometimes I have to wait several seconds before it activates on my iPhone.
iOS is maddeningly full of multiple personalities. Haven't you ever watched people blindly swipe up, down, left and right, press UI elements because they think they might do something, use finger gestures without knowing exactly which ones to use? Search blindly for simple ways to do simple things?
More often than not, trying to undo things they did unwittingly in the first place!
Undo is simple. Shame it is completely undiscoverable. Something that is one of the pillars of interface design.
No. Simplicity doesn't apply to iOS today. That went out the window years ago.
It's simple things like this that are so frustrating. Like how if siri presents a list, you can't say, "the second one." Instead you need to repeat your original request, which siri got wrong in the first place, so why would you repeat it and risk siri presenting a list again?
Or if I'm trying to control homekit, I can't say "turn my kitchen and living room lights to 50%." Siri gets confused and I have to say each one separately.
How does Apple not catch this simple stuff with dogfooding?
The same thing every year. All the experts (idiots) telling us how Apple screwed up and didn't add the features "THEY" think are required and are a dealbreaker for them to consider buying an iOS device. Followed by the fandroids proclaiming they had those features first and Apple is catching up to 2010. And so on.
In short, WWDC is the Apple haters worst nightmare.
As for folder navigation, I believe it's the way they intended it to be. They took a lot of time and pride building apps that are far easier to use for their specific purpose. Want music? Music app. Want books? Books app. Photos? Photos app.
They are moving away from the filesystem and improving the shortcomings with spotlight and AI. That's the way it is. I happen to appreciate it.
It is nice to have but not remotely as useful as in a desktop or laptop. If they don't get to introduce that, you always have Android. You will find Android settings being way messier.
iOS isn't without its faults. There is no perfection, you just have to find which imperfections you can live best with.
I agree with all of this, especially iOS and the iPad Pro.
IMO, iOS on the iPad should address [at least] 2 levels of users: the current consumer level; the pro level.
For example, in education, the Swift Playgrounds iPad app is an excellent vehicle to introduce coding to the masses (consumers). But to go to the pro level, where the user (developer) is actually writing, testing, maintaining production code -- you need to run Xcode on the iPad -- along with access to the file system, separate kb/cursor, etc. Apple's HandOff capability would be a real boon as it would allow you to pickup and go, taking your code and IDE with you.
Yeah, and why not enhance iOS to allow the iPad to act as an ad hoc display/kb/trackpad UI for headless computers such as Mac Minis, servers, etc.
The no direct transfer decision also runs into another problem. They take functionality away on the grounds that you might do something illegal with it (piracy). Of course, that is not Apple's or anybody's judgement to make on the users' behalf and makes little sense when what you want to do is simply transfer the photos you have just taken, directly to your friend's phone.
I was unaware that some Android phones lack the file transfer profile.
Because a typical app, whether iOS, tvOS, watchOS or macOS, requires lotsa' lotsa' files -- and you need to manipulate them.
Below is an email I just received from Swift@IBM.com for a simple app to send emails:
If you do the first 3 steps:
- download the project from Github
- run swift package generate-xcodeproj
- open the generated Xcode project
You will get hundreds of files (web server, SMTP server, logger, etc.) and thousands of lines of code:Below is the entire email from Swift@IBM.com:
- download them to somewhere (the file system)
- access the downloaded file structure to generate the Xcode project
I suppose, you could use a dumbed-down file system ala iOS Pages or iOS Swift Playgrounds -- but that would introduce inconsistencies/confusion between macOS use of Xcode and iOS use of Xcode.The whole thrust of Swift@IBM is to allow you to write/test/debug/maintain both the client-side and server-side locally -- before deployment. It is extremely productive to observe both sides of the application at once -- for debugging and implementing changes. The simple mail app involves a web server and an SMTP server -- it could easily involve separate database servers, several IBM Watson servers (translation, analytics, voice to text, etc.).
Here's how the app looks running both ends locally:
2) All apps have access to any file structure they wish to offer the user. This is why, for example, Finder, by default, hides certain files and folders; yet, it's still an archaic system on macOS users shouldn't have to deal with and that's not required for an app like Xcode that can access a hierarchal file system from within its own app. Same goes for the Dropbox app on iOS.
3) What you need to figure out is how the Mac version of Xcode could possible work with your fingertips as the primary input on a 4" to 13" display when it's hard enough to use the app on a 13" MBP with a mouse pointer and physical keyboard for input, not wonder how Apple will do something that it already does.
I suspect that IBM is pressuring Apple to provide this kind of [iOS-macOS] 'tweener capability for itself and for its IT customers writing/using/extending IBM's MobileFirst apps.