Apple's Swift Playgrounds 1.5 will teach kids how to write code for Lego, drones & robots

Posted:
in iPad edited June 2017
Apple on Thursday revealed that with a version 1.5 update on June 5 -- the beginning of WWDC 2017 -- Swift Playgrounds will include new material teaching people how to write programming for drones, robots, and similar electronics.




The company is working with several electronics makers to incorporate the content, namely Lego, Parrot, Sphero, Ubtech, Wonder Workshop, and Skoog. In-app projects will, for example, guide users through using Sphero's Sprk+ robot in a real-world version of "Pong."

The iPad app will also serve as a blank slate for more advanced coders, letting people build custom controls. People flying a Parrot drone will be able to specify yaw, pitch, and roll changes.

Swift Playgrounds has long been able to communicate with external hardware through Bluetooth, and some parties like Wonder Workshop have already been taking advantage of this. The 1.5 update should, however, make the feature more prominent.

Swift is an open-source programming language that works across Apple platforms. The company has been eager to foster adoption by both developers and students -- on May 24, it introduced a free year-long course available through the iBooks Store, which will even be taught at some U.S. colleges and high schools starting this fall.

Apple is likely unveiling the Playgrounds update now to clear the table for WWDC. The company is expected to make its first hardware announcements there since 2013, including new iPads, refreshed MacBooks, and possibly a rumored Siri home speaker.
«1

Comments

  • Reply 1 of 24
    red oakred oak Posts: 609member
    Wow.   They are really clearing the deck ahead of time for WWDC.   I'm shocked they did not announce this at the conference 
    randominternetperson
  • Reply 2 of 24
    tmaytmay Posts: 2,565member
    Dearest Apple,

    This is the part where you need to create an Arduino type hobbyist device programmable from the iPad/iPhone/Mac in Swift using a subset/superset of Xcode and iOS. It would be useful for a hobbyist to create motion control, robotic systems, and acquire data.

    Thank you in advance.
    jony0dewme
  • Reply 3 of 24
    dick applebaumdick applebaum Posts: 12,389member
    tmay said:
    Dearest Apple,

    This is the part where you need to create an Arduino type hobbyist device programmable from the iPad/iPhone/Mac in Swift using a subset/superset of Xcode and iOS. It would be useful for a hobbyist to create motion control, robotic systems, and acquire data.

    Thank you in advance.
    Bingo!

    jony0
  • Reply 4 of 24
    red oak said:
    Wow.   They are really clearing the deck ahead of time for WWDC.   I'm shocked they did not announce this at the conference 

    Exactly,  In years past they have cluttered up included this sort of announcement in the WWDC keynote.  So this could be sign that Apple has a ton of stuff to present.  Or they just realized that developers don't really care about this sort of announcement.
  • Reply 5 of 24
    JinTechJinTech Posts: 287member
    red oak said:
    Wow.   They are really clearing the deck ahead of time for WWDC.   I'm shocked they did not announce this at the conference 

    Exactly,  In years past they have cluttered up included this sort of announcement in the WWDC keynote.  So this could be sign that Apple has a ton of stuff to present.  Or they just realized that developers don't really care about this sort of announcement.
    I'm guessing they have a ton of stuff to present. After all, the keynote is scheduled till 12:00.
  • Reply 6 of 24
    georgie01georgie01 Posts: 132member
    randominternetperson said:

    In years past they have cluttered up included this sort of announcement in the WWDC keynote.  So this could be sign that Apple has a ton of stuff to present.  Or they just realized that developers don't really care about this sort of announcement.
    Developers don't really care about Swift Playgrounds for iPad since it offers them nothing, and it's not like they can build iDevice and mac apps with it. However, with greater possibilities it will attract hobbiest developers or code testing options, kind of like how playgrounds in Xcode provides a quick easy way to test and experiment with code.

    But I think there is probably some other really great stuff planned for WWDC that there's no need to announce this there. Hopefully, at least.
    randominternetperson
  • Reply 7 of 24
    mubailimubaili Posts: 376member
    red oak said:
    Wow.   They are really clearing the deck ahead of time for WWDC.   I'm shocked they did not announce this at the conference 
    Yea, and the App Store announcement too. there must be tons of stuff to be announced on Jun 5.
  • Reply 8 of 24
    kevin keekevin kee Posts: 821member
    I am ready.

    So, does that mean I could convert SDK to swift for my Sphero and create a custom app to control it from there?
    tmay
  • Reply 9 of 24
    longpathlongpath Posts: 193member
    Would rather see a version of Xcode for iOS... Lack of such an option keeps me from considering the iPad Pro.
  • Reply 10 of 24
    dick applebaumdick applebaum Posts: 12,389member
    I wonder if Devs will get a Swift 4 beta at wwdc.. Also, haven't had an Xcode update since April 18.


  • Reply 11 of 24
    mdriftmeyermdriftmeyer Posts: 7,101member
    longpath said:
    Would rather see a version of Xcode for iOS... Lack of such an option keeps me from considering the iPad Pro.
    I wouldn't. You don't need a 10GB Xcode in iOS. Sorry, but OS X is separate for a reason.
    randominternetpersonSolipscooter63
  • Reply 12 of 24
    dewmedewme Posts: 1,270member
    tmay said:
    Dearest Apple,

    This is the part where you need to create an Arduino type hobbyist device programmable from the iPad/iPhone/Mac in Swift using a subset/superset of Xcode and iOS. It would be useful for a hobbyist to create motion control, robotic systems, and acquire data.

    Thank you in advance.
    Yes indeed. The primary purpose of such a hobbyist device would be to supply modular programmable IO (digital, analog, pulse train, and various specialty functions) that is controlled and acted upon by Swift applications in the iOS device. The apps would still have full access to the iOS device's built-in sensors like GPS, cameras, microphone, LED flash, etc. I'm sure Apple could provide the Swift libraries needed to access the programmable IO. In essence the iOS device becomes a micro programmable controller (PLC/PAC) and the hobbyist device becomes the IO chassis, dock, and power supply. This would create a useful second life for older iPhones, iPod Touches, and iPads. These hobbyist modular programmable IO devices coupled with iOS devices and Swift programming would serve as a great platform for learning basic product development, control programming, human machine interface programming, robotics, process automation, machine control, etc., all of which are critical and highly in-demand skills today and for the foreseeable future.  
    edited June 2017
  • Reply 13 of 24
    SoliSoli Posts: 7,036member
    JinTech said:
    red oak said:
    Wow.   They are really clearing the deck ahead of time for WWDC.   I'm shocked they did not announce this at the conference 

    Exactly,  In years past they have cluttered up included this sort of announcement in the WWDC keynote.  So this could be sign that Apple has a ton of stuff to present.  Or they just realized that developers don't really care about this sort of announcement.
    I'm guessing they have a ton of stuff to present. After all, the keynote is scheduled till 12:00.
    That's interesting. I wonder if there's an event specific reason (like a special demo that requires more setup—for example, a live video showing the inside of Apple Park with natural sunlight at the peak of the day), if they just decided they need more time to setup in general that we should expect this for every special event, or some other reason.
  • Reply 14 of 24
    SpamSandwichSpamSandwich Posts: 29,068member
    Clearly this is proof that Apple is working on flying robots... CONFIRMED!
  • Reply 15 of 24
    MarvinMarvin Posts: 14,152moderator
    longpath said:
    Would rather see a version of Xcode for iOS... Lack of such an option keeps me from considering the iPad Pro.
    I wouldn't. You don't need a 10GB Xcode in iOS. Sorry, but OS X is separate for a reason.
    XCode is ~10GB due to the bundled platforms. The iPhone simulator platform alone is >3GB (right-click XCode, show package contents, Developer folder). When you are working on iOS, you don't need a second version of iOS as you can run the apps natively, the Mac has to use the simulator. Without all the platform files and documentation, XCode is <1GB. Documentation can be online.

    It wouldn't be easy to make Mac apps on iOS and full development capability could screw up the OS or dump large files somewhere they can't be removed easily. It couldn't be a straight port of XCode as a lot of temp build files go into the home folder. These would have to be kept inside a sandboxed location on iOS.

    It would be very useful to be able to work on apps with just an iPad though, even if it was just parts of an app that got synced to a code repo and the work was continued on a Mac at home. It would be faster to develop the UI of an iOS app on iOS itself as the touch capability is there and you can tell how the layout works on the display. It can simulate the smaller iOS screen sizes with scaling.
    jbishop1039
  • Reply 16 of 24
    SoliSoli Posts: 7,036member
    Marvin said:
    It would be very useful to be able to work on apps with just an iPad though, even if it was just parts of an app that got synced to a code repo and the work was continued on a Mac at home. It would be faster to develop the UI of an iOS app on iOS itself as the touch capability is there and you can tell how the layout works on the display. It can simulate the smaller iOS screen sizes with scaling.
    How exactly would Xcode for iOS be useful? I assume you've used the app on a Mac so I assume you've used it on a laptop display and wished you had a bigger display because it's such a complex app with so many features that need to accessed. How exactly would all that be useful with your fingertip as the primary input?
  • Reply 17 of 24
    MarvinMarvin Posts: 14,152moderator
    Soli said:
    Marvin said:
    It would be very useful to be able to work on apps with just an iPad though, even if it was just parts of an app that got synced to a code repo and the work was continued on a Mac at home. It would be faster to develop the UI of an iOS app on iOS itself as the touch capability is there and you can tell how the layout works on the display. It can simulate the smaller iOS screen sizes with scaling.
    How exactly would Xcode for iOS be useful? I assume you've used the app on a Mac so I assume you've used it on a laptop display and wished you had a bigger display because it's such a complex app with so many features that need to accessed. How exactly would all that be useful with your fingertip as the primary input?
    XCode has a lot of options but I wouldn't say a lot of features. It's mostly just taking code and compiling it. There are hundreds of settings and dropdowns but hardly any of them ever need to be changed and would be better hidden. Having an outline view of the code files and the text itself is enough to show and fits on a laptop display ok:



    Having the left sidebar visible all the time uses up some space but it can be hidden. The two right-most columns look just like having apps in split view on an iPad and Storyboards only needs to be open when doing the UI. Playgrounds for iOS is cut down to more of the essential UI parts:
    Image result for ios swift playgrounds
    When you compile and run with iOS XCode, it could collapse the UI and open the executable in a split view panel in order to debug the app with debug output in the other panel. In XCode on the Mac, the UI has more elements visible at a time because the space is there to use. Pretty much none of the title bar UI elements need to be on iOS.

    If you are targeting iOS then you have to run the app on the device anyway so being able to do that straight from the device saves having to tether the device and authorize it from the Mac. You also have to match a lot of things like Mac OS version plus XCode version plus iOS version. You hit compile, it has to build it then copy it over the wire to install it and then you pick up the device to use it, it crashes and you have to go back to the Mac to debug it and repeat.

    There are a number of benefits to doing it all on the iOS device. As mentioned earlier, it already has a touch UI so building and testing the UI and layout would be faster. It makes debugging faster because you can fix problems on the device without going back to the Mac and copying a fixed version over. It also allows people who are learning on their iOS devices to go the whole way of building and using their own apps:

    http://www.macworld.com/article/3147736/ios/heres-what-kids-really-think-of-apples-swift-playgrounds-learn-to-code-app.html

    Some people only have iPads and Windows machines. Once they are done with Playgrounds, they are out of luck until they can afford a Mac. A Mac isn't much more expensive that an iPad Pro but it's another device to buy in full on top of the iPad when the iPad is powerful enough to do it. There's no reason an iPad can't do everything productive that a Mac can.

    When it comes to the pointer input, it's more efficient for working with text to have one, the same is true for all text editing apps. Having a touch flap on the keyboard cover might suffice here that you pull out:



    That could have a cushioned top so that pressing into it is like 3D touch. Perhaps it would be best being a separate pad to be able to switch left/right and replace if it gets worn out but that would require its own battery, charging and bluetooth. If they had a magnetic attachment on the back of the iPad, that could charge it if it was separate. A 3D sensor can do a similar job either in the iPad or down the side of the keyboard. There might be a way to use the main keyboard for it by locking key input like how the software keyboard works, although dragging over the physical keys isn't ideal nor is having to lock/unlock key input each time. When using the pad, I'd expect it to show each finger on screen as a circle and they'd disappear when not touching the pad. The system would remember the location they were in and resume on touching the pad again. This would make selecting and editing text easier.

    Imagine having a split view with sidebar and code open. One finger on the pad shows a semi-transparent circle on-screen and you move it over the sidebar to choose a file. The file name can highlight when the circle is over it. Press into the cushion to select and the circle can become more opaque while pressing. The file would open. Two fingers on the pad can show two circles when scrolling. This also gives a visual reference for the anchor point when rotating and scaling. To move the text pointer, like with the file selection, drag to the location and then press to set it. Selecting text can have a keyboard key that you hold down so no more having to resize the selection handles. You can hold the selection key on the left and drag over the items to select (mostly lines at a time). Release the key to stop selecting. This allows selecting multiple portions of text at a time like separate functions in a code document and it can highlight selected items like a magic marker.

    This can work with a core filesystem as you can drag the pointer off the side of the screen to bring in a file view (like MacOS notifications). Saving images from Safari for example, you can be on a web page, do a selection highlighting all the images you want, copy them, drag over to the right to open the file viewer, open a collection and save selected images. Multiple finger swipe can open the multi-tasker with the touchpad, swipe over to an image app then open the image collection and use some of the images saved from Safari.
  • Reply 18 of 24
    SoliSoli Posts: 7,036member
    Marvin said:
    Soli said:
    Marvin said:
    It would be very useful to be able to work on apps with just an iPad though, even if it was just parts of an app that got synced to a code repo and the work was continued on a Mac at home. It would be faster to develop the UI of an iOS app on iOS itself as the touch capability is there and you can tell how the layout works on the display. It can simulate the smaller iOS screen sizes with scaling.
    How exactly would Xcode for iOS be useful? I assume you've used the app on a Mac so I assume you've used it on a laptop display and wished you had a bigger display because it's such a complex app with so many features that need to accessed. How exactly would all that be useful with your fingertip as the primary input?
    XCode has a lot of options but I wouldn't say a lot of features.
    All those active settings you have to manipulate constantly on the all panels that you slide in and out of constantly and click on a subcategory of that panel with a button a fraction the size of your finger tip are features to the app.
  • Reply 19 of 24
    MarvinMarvin Posts: 14,152moderator
    Soli said:
    Marvin said:
    Soli said:
    Marvin said:
    It would be very useful to be able to work on apps with just an iPad though, even if it was just parts of an app that got synced to a code repo and the work was continued on a Mac at home. It would be faster to develop the UI of an iOS app on iOS itself as the touch capability is there and you can tell how the layout works on the display. It can simulate the smaller iOS screen sizes with scaling.
    How exactly would Xcode for iOS be useful? I assume you've used the app on a Mac so I assume you've used it on a laptop display and wished you had a bigger display because it's such a complex app with so many features that need to accessed. How exactly would all that be useful with your fingertip as the primary input?
    XCode has a lot of options but I wouldn't say a lot of features.
    All those active settings you have to manipulate constantly on the all panels that you slide in and out of constantly and click on a subcategory of that panel with a button a fraction the size of your finger tip are features to the app.
    If you mean the panels on the right in the following image, the UI has been designed for the space available on the Mac, it would be done differently on iOS:



    There's no need to show all the sub panels at once. Because things like pinch-zoom are easier on iOS, you can scale UI elements up/down as needed and you can have a lot more contextual settings. All of the settings and hierarchy panels can be removed to leave just the UI layout view, which you can zoom in and out of and select elements as needed. When you select an item, there can be larger buttons to open size options, another to open the library panels.

    The 4-tab library panel at the bottom right can even be replaced with a single plus icon to add something. When a text window is active, you can only add code snippets. It knows which language you are using so it would limit the snippets to the relevant kind and you can type in the search to narrow it down. When a Storyboard is active, tapping plus would popup icons for controller/button/view/toolbar and tap one to get the relevant items and again it can limit the results based on the active selection.

    XCode for the Mac would be better being simplified because there's far too many settings in every panel, most of which people will leave at the default settings anyway. They can have a preference somewhere to show expanded options. Build settings for example has so many options that it makes it hard to find the settings you do need often like provisioning options. That whole build area should be cut down to just the essentials by default: target architecture and provisioning profile, 1 dropdown ideally for each. Have a settings panel somewhere with a set of checkboxes to enable the other options. The items visible by default should be options that people change most. If a setting is only changed or used by <1% of developers, there's no need to clutter everybody's UI with it. Those developers can enable the extra options they need.

    XCode's app templates would be helpful if they were also more specific. A lot of people make games for example so they can have templates for sidescrollers, first-person shooters, racing games and as soon as you pick a template, it's a fully working game but all textures and models are basic. There can be online libraries of paid content like models, textures, audio that people can use in their apps. Someone building a racing game can get the template, go to the content library and get some trees, buildings, cars, audio, individually or for a pack, either free or paid and drop them into their template.

    Part of what makes software development so slow is people reinventing the wheel for every app. There are millions of apps that deal with common categories of content, Apple can check the most common UI structures and app types across the store and provide templates to build those kinds of apps e.g if a restaurant or hairdresser wants a booking system, they can have an app template for it as well as an online component like an iCloud database where they can manage their content, possibly controlled via FileMaker (extra $99 per year on top of developer license).

    Profiling can be made easier too. The point of profiling is to get apps to perform better but profiling usually gives incomprehensible traces of things that don't help fix the problems. The vast majority of the time, people need to know how long is code taking to run and how much memory is being used by what. There can be one button that checks how an app is performing and it can highlight the code that is running too slow and the objects using too much memory.

    It benefits everyone for software development to be more accessible. It's like how computers don't need to be controlled by the command-line. When you have an abstract UI, you can do tasks more easily, which can improve productivity as you aren't getting blocked by having to learn an unintuitive system. There was a site built recently to help learn coding linked with the Wonder Woman movie:

    https://www.madewithcode.com/projects/wonderwoman

    That's just drag and drop code blocks and is very accessible to people because there's only high level concepts to think about - characters, actions, variables etc. That's what software development should be for most people.

    It might actually be an idea for Apple to put together a team of inexperienced developers who want to make apps to describe how they want to build apps rather than have developers try to simplify traditional workflows. They would focus on trying to get the time down from starting at zero to a deployable app for inexperienced developers and fix every hurdle along the way.

    The following is an example of where software development becomes complete nonsense:

    https://medium.com/@johnsundell/handling-non-optional-optionals-in-swift-e5706390f56f

    That whole page is talking about what is the best way to handle potentially nil data and suggesting crashing the app might be ok. Allowing software to crash is the most user-unfriendly approach. This is the kind of thing that holds back software development because they try and make developers individually figure out problems that shouldn't be theirs in the first place. When an app gets into an invalid state, it should tell the user what's going on. When an app hangs, it should interrupt its own execution and allow the user to take control of it rather than rely on the OS to kill it. Apps should behave like operating systems, they don't require rebooting every time something goes wrong. When something goes wrong, there should be a facility to inspect what went wrong, recover from it and report it. The software architecture itself should be fault-tolerant and handle the problem and not put that burden on developers to have to architect their own solutions.

    They can have a rollback system. Mark data that's not supposed to be nil or out of bounds and if it isn't handled, roll the execution cycle back to before it went wrong and tell the user that doing what they just did caused something to go wrong, trace the rollback and send it to the developer. Same goes for memory errors, or infinite loops. Apple's mantra of 'simplicity is the ultimate sophistication' is lacking in software development environments.
    edited June 2017
  • Reply 20 of 24
    Mike WuertheleMike Wuerthele Posts: 2,530administrator
    Re-focusing on the topic at hand. My children and I will be examining this over the summer.
Sign In or Register to comment.