Under The Bridge Under The Bridge

Category: Tools
The Xth-Code Files: Xcode 10 Tips

Now that we’ve hopefully all got our iOS 12 and Swift 4.2 migrations under control, let’s catch our breath and dive a little deeper into what’s new since last year with Xcode 10, shall we? 

What’s New in Xcode

Dark Mode Interface and Mac App Support

  • All-new dark appearance throughout Xcode and Instruments
  • Asset catalogs add dark and light variants for custom colors and image assets
  • Interface Builder switches between dark and light previews of your interface
  • Debug your Mac apps in dark or light variants without changing OS settings

Source Control

  • Changes in the local repository or upstream on a shared server are highlighted directly within the editor…
  • Support for cloud-hosted and self-hosted Git server offerings from Atlassian Bitbucket, as well as GitLab to go along with existing GitHub support.
  • Xcode offers to rebase your changes when pulling the latest version of code from your repository.
  • SSH keys are generated if needed, and uploaded to service providers for you.

Editor Enhancements

  • Place multiple cursors in your code editor to make many changes at once.
  • Code folding ribbon can now hide any code block surrounded by braces.
  • Over-scroll makes it easy to center the last lines of code in the middle of your screen.

Playgrounds Built for Machine Learning

  • New REPL-like model reruns your existing playground code instantly.
  • Run your code up to any specific line, or type shift-return to run the code you just added.
  • Import the Create ML framework to interactively train new models, and then write code to test the model right in the playground. When finished, drag the model into your app.

Testing and Debugging

  • Debugging symbols are downloaded from a new device five times faster than before.
  • Xcode will spawn a collection of identical Simulators to take advantage of your multi-core Mac, and fan tests out to run in parallel, completing your test suite many times faster.
  • Run tests in random or linear order.
  • Instruments automatically show OSLog signposts you add into your code.
  • Build and share your own custom instruments package to provide unique data visualization and analysis for your own code.
  • Memory debugger uses a compact layout to make it easier to investigate your memory graph.
  • Metal shader debugger lets you easily inspect the execution of your vertex, fragment, compute, and tile shader code.
  • Metal dependency viewer provides a detailed graph of how resources are used in your Metal-based app.

Build Performance

  • New build system enabled by default with improved performance throughout.
  • Swift compiler builds each individual file significantly faster.
  • Large Swift projects build for debugging dramatically faster when using the incremental build setting.

That’s a pretty good selection of improvements, yes? And we have an admirably exhaustive collection of release notes to dig deeper:

Xcode 10 Release Notes

Interface Builder Release Notes for Xcode 10

Build System Release Notes for Xcode 10

Source Editor Release Notes for Xcode 10

Swift 4 .2 Release Notes for Xcode 10

So, we recommend you Read Them All! of course, but here let’s call out the things that you definitely don’t to overlook. #1 is your optimization flags:

If you’ve been around for a while, chances are you’ve set Whole Module Optimization for your project. This is now incorrect: it prevents incremental builds and those are faster. For the definitive word on that, see What’s New in Swift from WWDC 2018, at 11:40:

Stop Using Debug with Whole Module Compilation

Doesn’t get more explicit than that!

As well, there’s a new Build with Timing Summary action (or -buildWithTimingSummary flag to -xcodebuild) that will tell you exactly where all the time is going. There’s a pair of articles here that go into more detail on those and other goodies:

Enabling newly added opt-in features in Xcode 10

Build performance analysing in Xcode 10

#2, now that you’ve got the compilation flags settled, is how to parallelize your building as much as possible. There’s a new Parallelize Build option in your scheme’s build settings, and if it’s not checked, go check it. With some luck, it’ll all Just Work™, but if you have any code generating phases — we like R.swift, for instance — you’re going to find that parallelization isn’t going to work until you set the script file output filenames properly. This, and a good bit more, is explained in detail at

Improving Your Build Time in Xcode 10

#3 — speaking of parallelization — is that now your tests can be run in parallel, and randomized to boot, to make sure that you don’t have any implicit dependencies in your tests! Those are another couple optin checkboxes — for full details watch WWDC 2018’s What’s New in Testing, or check the notes at

WWDC 2018 What’s New in Testing Recap

That’s about it for the major active actions you need take to make your project Xcode 10 savvy, but there’s plenty more nuggets to dig up. For instance, exporting NSData easily:

Xcode 10 has a new QuickLook popover for (NS)Data. It now provides an “Export” feature that can be used to dump memory contents to a file. This is very convenient when you want to investigate data with external editors. (e.g. the fantastic HexFiend)

Also, you’ve no doubt noticed already that the Library is now its own window, and may have found its behaviour somewhat opaque — to keep it open by holding down Option, and some more power tips, check out

Xcode 10 Library Tips

Xcode 10 Storyboard Changes

And let’s not fail to not your annual reminder to clean your old Simulators:

$ xcrun simctl delete unavailable
$ rm -rf ~/Library/Developer/Xcode/iOS\ DeviceSupport/

That should free up at least a few gigs for you. 

Finally, if you’re really interested in digging into Xcode trivia deeper than “delete it whenever things start acting squirrely,” check out:

What’s inside the Derived Data folder?

UPDATES:

Unleashing the power of asset catalogs and bundles on iOS

Xcode & Instruments: Measuring Launch time, CPU Usage, Memory Leaks, Energy Impact and Frame Rate

Building an iOS App Without Xcode’s Build System

awesome-xcode-extensions: “Awesome native Xcode extensions.”

The hidden value of Xcode schemes

Xcode Environment Specific Configuration

Homemade Marzipan Recipes: UIKit on macOS

Well, we are definitely going to accept credulously everything Mark Gurman tells us from now on, because he called it six months early: Yes, UIKit is coming to macOS, and it is, in fact, code named “Marzipan”— top marks! And there’s been a wide range of reactions to that, the best collected (as usual!) over at Michael Tsai’s blog:

Apple Announces Marzipan for 2019

One particularly notable contrarian voice can be found at Apple Didn’t Kill AppKit, Millenials Did:

But here’s the painful part: the techniques to do these things are already available, well-known, and very few people are using them. There are still lots of iPhone-only apps, or apps that make poor use of the iPad and just let their table views stretch out to infinity. And as for tvOS… it already runs UIKit. Your scenes are actual damn UIViewControllers. And yet look at the dearth of TV apps. We’ve had Marzipan on the TV for years and almost nobody uses it…

Well yes, that’s a good argument, and yes, it’s not all that hard to make a UIKit+AppKit app now if you want to, 

To be clear, the enemy is not other Apple-platform developers. The enemy is the use of bloated, cross-platform, phone-it-in frameworks. “Write once, run everywhere” has been promised and come up wanting for decades: Java applications and applets, Adobe AIR, Xamarin, PhoneGap, and so on. One semi-success story of recent years are the various approaches like Electron and Chromium, which effectively embed an entire instance of the Chrome web browser in an app wrapper. This approach is used by such Mac apps as Slack, Discord, and Spotify.

It is also a goddamned scourge, and straight up an abuse of the end-user’s equipment.

And yes, yes, that too.

However, none of these objections are particularly subtle, and yet Apple’s put a couple years so far into this and is doubling down. All in order to save, spitballing here, maybe 15-25% of any well-architected app would need to be different? Well, that makes people figure, also quite reasonably, that the real agenda here is to support the ARM Macs That Everyone Expects Sooner Or Later:

Marzipan as a Path to ARM Based Macs

What if MacOS on ARM only ran these new UIKit apps?

That’s a scary thought for this MacOS developer.

But then again, we already have this and it’s called iOS on the iPad. And maybe, just maybe, and remember these are half baked thoughts, but maybe Apple is wondering if some Pro users might be better served by MacOS Touch 1.0 running on ARM.

An interesting perspective. But, as announced, Apple is using it themselves, so we know that they evaluated the cross-platform strategy ably ranted on behalf of above, and they decided it made more sense to engineer this Grand UIKit Emulation Layer … well, for some reason. Be fascinating to find out what next year or two!

In the meantime, what’s shipping now is surprisingly functional, people are finding:

and although it’s generally agreed that you shouldn’t pay too much attention to the current implementation details, if you want to have some quick fun:

marzipanify

marzipanify is an unsupported commandline tool to take an existing iOS Simulator binary (with minimum deployment target of iOS 12.0) and statically convert it and its embedded libraries & frameworks to run on macOS 10.14’s UIKit runtime (Marzipan)…

MarzipanTool  — Port an iOS app to macOS 10.14 in 5 minutes

Here’s how to port your iOS apps to macOS 10.14 Beta using Apple’s iOSMac/Marzipan framework. A “Hello World” iOS app can become a macOS app in less than 5 minutes. (I timed it.).

Marzipan Platter

At WWDC 2018 Apple announced that they are working on a multi-year strategy to make it easier to port UIKit applications to the Mac. While some first-party applications such as the Home & News app are going to use this API in macOS 10.14, third-party developers won’t have official access for another year. As a result, I made this project to help tinkerers/other impatient people get a taste of what’s to come when Apple gives everyone access to Marzipan next year…

Marzipan – UIKit on macOS

For this post I prepared a very simple app — that allows you to fetch top stories from Hacker News and present them in a simple UITableView. This app is simple as far as functionality is concerned but includes some standard plumbing and networking to see whether common libraries can be used on macOS. The good news is that this is indeed possible and we can use libraries like Alamofire, Swinject and others without any special effort!

So, it doesn’t take too much to figure that Marzipan is going to be extremely important in the not so distant future … get started today!

But please, don’t do what this guy did, even tongue in cheek and all…

Marzipants

Here’s a proof-of-concept that React Native can work* (*lol) under Marzipan.

But, like, it’s proof that we don’t need Electron, right? 💪

… It’s surprising how well it’s working. Besides the obvious mobile-specific things, it’s running abouuuut as well as tvOS builds of React Native.

I wouldn’t recommend using it. Ever. C’mon now.

UPDATES:

Marzipan: Porting iOS Apps to the Mac

Flutter Flutter Little App

 

So things were not all that terribly interesting at Google I/O this year, at least as far as iOS developers are concerned — 

100 things we announced at I/O ‘18

— until you get down to

90. We shipped Flutter Beta 3, the latest version of our mobile app SDK for creating high-quality, native user experiences on iOS and Android…

That’s always an interesting claim, isn’t it? Well, allegedly it’s

Ready for Production Apps: Flutter Beta 3

This week at Google I/O, we’re announcing the third beta release of Flutter, our mobile app SDK for creating high-quality, native user experiences on iOS and Android, along with showcasing new tooling partners, usage of Flutter by several high-profile customers, and announcing official support from the Material team.

We believe mobile development needs an upgrade. All too often, developers are forced to compromise between quality and productivity: either building the same application twice on both iOS and Android, or settling for a cross-platform solution that makes it hard to deliver the native experience that customers demand. This is why we built Flutter: to offer a new path for mobile development, focused foremost on native performance, advanced visuals, and dramatically improving developer velocity and productivity…

Well, to our ears, this has a distinct ring of the claims made for cross-platform development by for instance Xamarin, which tend to not be widely shared by those who actually attempt to ship products with them:

Xamarin SUCKS! Lessons learned from weeks wasted

I’m really sorry for the language, but this software is simply and literally the worst mega f***ing shit I’ve ever used in my life. This halfass piece of garbage only serves to waste people time. And IKR, how could people pay for this, ffs?!

… SO TO ANYONE OUT THERE WHO, LIKE ME, THOUGHT “HEY, IT CAN’T BE THAT BAD, CAN IT? I’LL JUST SPEND A FEW HOURS, MAYBE A DAY SETTING THINGS UP BUT IT WILL PAY FOR ITSELF”. NO. GO BACK. IT WON’T PAY. IT’LL NEVER PAY. IN FACT, IF YOUR DREAM IS TO WORK AT MICROSOFT THEN MAYBE YOU SHOULD STICK TO XAMARIN. BECAUSE YOU’LL FEEL LIKE YOU’RE FIXING XAMARIN’S BUGS, NOT YOURS. IN FACT, SOMETIMES YOU’LL EVEN FORGET ABOUT YOUR PROJECT. YOU’LL BE JUST LIKE “WTF IS THIS PROJECT DOING HERE? OH, IT’S MINE”, BECAUSE YOU’LL BE SO INTO XAMARIN BUGS. YOU’LL START THINKING ABOUT GOING TO GITHUB AND FIX XAMARIN INSTEAD OF YOUR OWN CODE (SERIOUSLY). THIS IS A DISEASE. DO NOT GO ANY FURTHER. YOU’VE BEEN WARNED.

Don’t hold back there, tell us how you really feel why don’t you?

Or, there’s always the trendy flavor of the last couple years before people actually started trying to maintain real apps with it, React Native:

Native > Flutter > React Native

As we all know there are a lot of cross-platform development frameworks but none beats the user experience of a natively developed application. A few months back here I was trying to appeal for React Native. But when I took it for a full spin for a fun project. I fell flat on my face.

There were many shortcomings when it came to React Native. Since mobile applications heavily depend on swipe-based user interaction and React Native heavily depends on a bridge that makes the JS code run on the native engine. This caused a lot of janking due to bottleneck. List Views using React Native was a nightmare…

Well, that fellow is optimistic about Flutter’s potential, apparently once bitten still not shy. Give it a couple more decades, you’ll be cynical as a troll, just watch … either that or burnt out completely, there does not appear to be any middle ground.

For some additional supporting evidence, here’s hands on experience:

How fast is Flutter? I built a stopwatch app to find out.

According to the docs, high performance is to be expected:

Flutter is designed to help developers easily achieve a constant 60fps.
But what about CPU utilization?

TL;DR: Not as good as native. And you have to do it right…

Now, not as good as native, that’s not stopping people shipping apps with it, check out the Showcase here. As we write this, the Hamilton musical app is the flagship example of a shipping cross-platform Flutter app, and the builders veritably ecstaticize themselves over the experience here: 

Rise Up! — The story of how the Hamilton App uses Flutter to do more for its fans

So there is definitely the potential here to suck less than other cross-platform solutions — not to imply that’s a high bar! — and it’s always good to have options available, yes?

So if you are interested in Flutter —

— and it definitely looks worth at least keeping an eye on to see if it gains further traction or slides into the shambling undeadness of past Google abandoned failures —

— here’s some resources to check out:

Flutter @ Google I/O 2018 YouTube playlist from @flutterio

Udacity’s free Build Native Mobile Apps with Flutter course

… and of course the Wenderlich tutorial empire is staking territory out here already:

Getting Started with Flutter

Getting Started with Flutter in Android Studio screencast

Flutter Navigation Tutorial

And if you, Dear Reader, happen to have some experience building a non-trivial application with Flutter, be sure to let us know how it went!

UPDATES:

Flutter vs React Native: A Developer’s Perspective 

Review: Continuous Delivery for Mobile with fastlane

 We’ve been idly following fastlane since it was just deliver, and it has had a lively lifespan indeed from obscurity to Twitter to Google and all; so it’s reasonably sure it’s approaching industry standard status at this point, which would make a canonical introduction to it handy indeed. And, why, look what we have to review today, a shiny new copy of

Continuous Delivery for Mobile with fastlane

Fastlane Book Cover

 

Competitive mobile apps depend strongly on the development team’s ability to deliver successful releases, consistently and often. Although continuous integration took a more mainstream priority among the development industry, companies are starting to realize the importance of continuity beyond integration and testing…

What You Will Learn

  • Harness the fastlane tools for the Continuous Deployment strategy
  • Integrate Continuous Deployment with existing Continuous Integration.
  • Automate upload of screenshots across all device screen-sizes
  • Manage push notifications, provisioning profiles, and code-signing certificates
  • Orchestrate automated build and deployments of new versions of your app
  • Regulate your TestFlight users and on-board new testers

It’s actually not 100% accurate, that title; a more accurate one would be “The Complete Beginner’s Guide To How To Ship An iOS App With fastlane Making It Suck Less.” That wasn’t quite as buzzword-compliant, we suppose.

If you do happen to be an iOS-focused complete beginner at dealing with iTunes Connect and all, and you intend to follow the common path of Crashlytics and/or TestFlight for beta distribution … then yes, we believe we can recommend this unqualifiedly as the most coherent introduction out there, go buy it and you can stop reading now!

If you’ve already got this distribution thing sussed, and you’re just curious about whether this fastlane thing that all the cool kids are into these days is worth adopting … hmmm, we’ll give it a three out of five. It’s worthy at explaining what it does explain, but to make it five-star for the more accomplished developer, we’d need two star-worthy things:

1. Documentation on the Android setup and shipping process as thorough as there is for iOS. There’s about six pages worth here, which is pretty thin compared to the iOS coverage. 

If you couldn’t care less about shipping for Android, of course, then this is not a valid criticism.

2. More thorough examples of how to integrate with CI and testing services other than the selected ones, to actually deserve the Continuous Delivery label. As a specific omission we were looking for, the book promises

The next step in this beta lane is to distribute our app via two popular testing platforms: TestFlight and HockeyApp.

… and then goes on to not deliver on this promise for HockeyApp. Since that was, in fact, the main thing we were looking for in this book, how to set it up with a HockeyApp-centric workflow, we were disappointed. So we figure that we’ll take another point off for not being an encyclopedic reference. Yes, we’re brutal. Again, if you are a complete beginner and/or you do use the standard tools that the book does cover, this is not a valid criticism either.

Should you be teetering, here is the publisher’s page and you can check out the TOC and all; plus the code repo for the examples — adding fastlane to Firefox — is here on Github.

But definitely, if you know anyone who’s just getting into iOS development, we’d rate this the best introduction there is out there without question!

On the other hand, as long as we’re talking about fastlane and all, there is the odd pocket of resistance to it you might read for balance:

Five Options for iOS Continuous Delivery Without Fastlane

If you’re looking to escape Fastlane’s frequent build-breaking changes, these five options for iOS continuous delivery are worth examining…

… but that’s definitely a minority opinion, most people find it adds at least some value.

As an example, up there where I docked it a point for not including less popular CI/deployment options? Here is an example of one such:

How to set up GitLab Continuous Integration for iOS projects without a hassle

Why GitLab-CI?

We had GitLab and we couldn’t find any reason for using something else. So, we decided to use it, why not 😎? As for me, the GitLab-CI/CD is more developer-oriented than Jenkins. At least because it is aimed at the pipelines, tags, and branches, unlike Jenkins with jobs. And we have to use those things to get the necessary job instead of configuration without code. GitLab-CI/CD seems like a tool for running scripts on a remote machine; no more, but enough.

Some time later, we realized what it doesn’t matter what to use if we use Fastlane. Because it was able to do all what we needed. As the result, we got freedom from other tools. So I can strongly recommend using Fastlane instead of manual scripts or other approaches…

And, of course, we do find several mentions of “Hockey” over at 

fastlane/examples: “A collection of example fastlane setups”

so it’s not as if their omission is a crippling lack in any way. We just figure a book like this should aim for canonical completeness!

UPDATES:

Build it, Test it, Deliver it! Complete iOS Guide on Continuous Delivery with fastlane and Jenkins

Effortless iOS Code Signing With Match

CI + CD: Looking For A New Buddy?

So first off, congratulations to our ex-neighbours (before we moved to Bangkok and all) for becoming another Vancouver company acquired by Apple!

The buddybuild team is now part of Apple!

We’re excited to share that the buddybuild team has joined the Xcode engineering group at Apple to build amazing developer tools for the entire iOS community.

We’ve always been proud to be a Canadian company, so we’re also pleased that we will be staying right here in Vancouver — a hotbed of developer and engineering talent.

The buddybuild service will remain available to existing customers to build, test, and ship iOS apps to testers through buddybuild.com… SWEET! Big win all around, right? Right?

As of today, we are no longer accepting new customers. Existing Free Starter plans and Android app development will be discontinued on March 1, 2018…

… oh. So if you’re a little indie and/or you have an Android version, not so much then.

Well, while we can hope that this promises that our developer memberships may be including some level of CI service in the nearish future, it’s just about a guaranteed certainty that the Android side is about to become just as much a dimly remembered history as that of TestFlight. Looks like just about the same scenario in fact, only difference this time is they announced Apple’s acquisition first!

So, let’s take a look around at what options there are for the indie developer who feels the pain of those free + Android plans going away, shall we?

Here is one particular instance of that discussion being conducted online, as an issue for GitHawk:

Alternatives to Buddybuild? #1330

We will almost certainly lose support for this project. Time to find a new CI. Any suggestions? I’m reading

this article

which offers:

BitriseTravis CINevercodeCircleCI

I read about Buildkite and AppCenter on Hacker News.

I’m also considering open source, self-hosted solutions so that something like this doesn’t happen again:

DroneJenkins Read through the whole discussion there: other options that showed up were

No strong consensus there, although Bitrise and Circle have positive buzz and Travis doesn’t, that’s what stands out.

Circle has an article here:

Migrating from buddybuild to CircleCI

If you enjoy managing everything with fastlane, looks like that’s the service for you. Those of us who want the magic to just work, we’ll keep looking a bit.

Here’s another fellow who went through the evaluation process and came up with a surprising answer:

Exploring Alternatives to buddybuild

In the end, I chose to go with

GitLab CI

. GitLab CI works very similarly to BuildKite: it merely coordinates a set of agents (“runners” in GitLab parlance), who are responsible for the actual building of the project. I’m already running a GitLab server to host my Git repositories, so using it for CI didn’t require any new installation or setup for my existing repositories…

… As I said above, GitLab CI is almost certainly not the right solution for your case. It’s the right solution for me, because a) it’s cheap, b) I was already running a GitLab server, and c) none of the other alternatives fit my needs quite as well. OK, if you’re using GitLab, self-hosted or not, that looks like the really obvious choice!

How to set up GitLab CI for iOS in three relatively simple steps

While GitLab is a fascinating option, we expect that Github is where indie projects are likeliest to live … ours, anyways. And, as you may remember, we were kinda impressed with Microsoft’s plans for Visual Studio App Center, and haven’t had any reason to go back on that since. And in what is possibly not a complete coincidence, they recently posted

Build Any App with Visual Studio App Center

At Microsoft, we strive to deliver the best developer tools on the planet in order to help make all developers more productive. With

Visual Studio App Center

, you can easily automate your DevOps lifecycle to continuously build, test, release, and monitor your apps on every platform, so you have more time to focus on your users and their experience.

The App Center Build service is completely free for your first 240 build minutes per month (up to 30 minutes per build) and supports iOS, macOS, Windows, and, of course, Android apps.

App Center supports apps written in Obj-C, Swift, Java, React Native, and Xamarin, and integrates with existing tools such as GitHub, Visual Studio Team Services, and Bitbucket. Once you’ve selected your repository, setting up build automation for any branch of your desktop and mobile apps takes just a few clicks. Additionally, App Center Build includes other cloud services, so you can run UI tests to retain the highest quality standards and distribute your apps to testers… That’s the one we’re going to try next, personally; find out for ourselves just how usable in practice App Center is, because it sure looks like the best multiplatform development support out there, and one that we can trust has just about as low a probability as possible of being acquired or discontinued … which seems to occur with depressing regularity to these tools of ours, doesn’t it now?

And as a parting note, here’s some more informed commentary and interesting speculation for WWDC 2018. Cloud Xcode Server would certainly be nice!

Apple Acquires BuddyBuild. Oh, My Xcode Server!

UPDATES:

Adding GitLab CI Support (followup to Exploring Alternatives to buddybuild)

Continuous integration and delivery with fastlane and CircleCI

Why XOD switched from Travis to Circle CI

Looking for Buddybuild Alternatives? Try App Center

Three Quick Tips: Signing Your iOS Apps with Visual Studio App Center Build

App Center: Continuous Integration and Delivery for iOS

Mobile CI/CD 101

Continuous Integration Services for iPhone Apps in 2018

Top Mobile Continuous Integration Tools

How to set up a CI for multiple iOS and tvOS Apps using Fastlane and Bitrise

TestFlight Tutorial: iOS Beta Testing

Windmill: “Your companion for seamless iOS development”

Hello WRLD: VR Developer Challenge

So ARKit by itself is pretty interesting, and adding Core Location to it gets even more interesting, but for the perfect trifecta, what do we need? Why, we need a VR world, so that we can explore real world locations without actually being there, amirite?

Well, turns out there’s an SDK for that: WRLD!

YOUR WORLD, REIMAGINED
A dynamic 3D mapping platform for smart cities and buildings, gaming, AR/VR experiences, and more.

Apparently they’ve been around for several years as “eeGeo”, but the much improved rebranding is new:

We are excited to announce today our rebrand of eeGeo to WRLD. We believe the name reflects the scope and breadth of our vision, which is to build an immersive 3D world to visualise and interact with every thing on the planet.

We’ve set an ambitious goal with our new name and vision on purpose. We can’t do it alone, as we globally operate as a collaboration between partners and our developer community. We’re committed to providing the best tools to build fully immersive experiences that benefit users in numerous ways – greater spatial understanding and decisioning, smart cities and building planning, or just creating awesome location-based games and VR experiences…

Yep, that’s pretty darn interesting. We’d already had some interesting ideas for how to mash up ARKit with real world locations, but were kinda stymied by the “well, it would only be interesting if you were actually there…” thing. But if you could take your informational ARKit app and place it in VR world instead of real world, well that gets rather more interesting, doesn’t it?

And as it happens, there’s an opportunity to get some recognition for your experiments:

WRLD DEVELOPER CHALLENGE

What if you had the WRLD at your fingertips? What would you create?

WRLD is hosting a global challenge for developers to create the most useful application or immersive experience using any of the WRLD SDKs.

Contest starts October 1st and final submissions are due December 31st.

#WRLDChallenge

 

Hello WRLD Challenge

 

So there you go, have at it!

Follow The Script

Between writing our client apps in Swift and looking forward to writing our server apps in Swift, we tend to overlook that Swift can be used as a scripting language as well — seriously, is there anything it can’t do? — so here’s how you do that using Xcode:

A Beginner’s Guide to Scripting in Swift

First, you’ll need to start with a new Xcode OS X Command Line Tool Application … The cool part here is that you can even import frameworks like Foundation. Anything you can do with Foundation, you can put into a script — this includes File I/O, string manipulation, and more … Your script can even accept arguments. Just append whatever you want after your execution command to add your arguments like a regular script…

Scripting is a powerful asset and a useful tool in any programmer’s tool belt. For many iOS Devs, Swift or Objective-C are the only languages they know. If they know Swift, then there is no need to learn Python or another scripting language when writing simple scripts for any automation process.

End-to-end development and deployment with nothing but Swift? Shiny!

Another introduction here:

Scripting in Swift

A shell script is perhaps the most popular command-line scripting language, particularly in the mobile development world. To test the viability of scripting in Swift, we’ll write our markdown converter first as a shell script and then compose a Swift version. We’ll then do a quick comparison of the pros and cons of each script…

And one more example from @ayanonagon (and Swift Scripting talk here):

Swift Scripting By Example: Generating Acknowledgements For CocoaPods & Carthage Dependencies

We started using both CocoaPods and Carthage to manage our dependencies, and we wanted to add a nice little view in our app that shows a list of open-source acknowledgements and licenses. We have around 20 dependencies, and the thought of adding the acknowledgements manually sounded tedious…

Indeed it is. Well, that’s definitely our first experiment in integrating Swift scripts into our production process, then!

UPDATES:

Swift Scripting Redux: Localization

Running The Swift 3.0 Migrator On A Standalone Swift File

Command Line Swift

Scriptarian: “allows you to easily automate macOS using the Swift programming language, providing a modern alternative to AppleScript.”

Marathon “makes it easy to write, run and manage your Swift scripts.”

Scripting and Compiling Swift on the Command Line

How to Make a Web Crawler in Swift

Beak: “A command line interface for your Swift scripts”

Swift, plist, and Two Smoking Scripts