Buried underneath the red shirt like death of Windows 10 Mobile lies the amazing Universal Windows Platform (UWP).
- Full developer parity at the API and framework level across all flavors of Windows 10, Xbox One, HoloLens, and Windows 10 Mobile devices.
- A simplified install model via APPX bundles.
- A per-app separation of registry and file systems.
- XAML controls ‘just work’ across all Windows 10 / UWP devices.
- Targeting the UWP API set ensures that your app works across Windows 10 / UWP devices.
In my experience, there is nothing weirder than seeing your Windows 10 / UWP app just work on an Xbox One, in a virtual projected rectangle via a HoloLens, and via mouse and keyboard on a standard Windows 10 PC.
UWP fits within a completely different vertical of development than the existing Windows Desktop technologies of Windows Presentation Foundation (WPF) and Windows Forms. As such UWP has access to the more modern feature set common to Windows Store applications. UWP has both duplication and subsets of API / XAML features that exist within WPF.
Right now may be a good time to take a look at your existing Windows Desktop apps and assess if they can be moved to UWP.
A UWP port of your legacy desktop app will allow access to modern UWP features:
- Live tile support
- Push notifications
- Background Downloader
There are 3 primary techniques to bring your current legacy desktop app to UWP:
- Project Centennial
- Straight UWP + Portable Library Breakout
- Brokered Windows Runtime Components
Microsoft’s Project Centennial can be thought of as a UWP enabling wrapper for your existing Windows Desktop app. You may be able to repackage your existing Windows Desktop application and run it as a UWP app via a Project Centennial wrapper on the forthcoming Windows 10 Anniversary Update. As with all huge development efforts, there may be some caveats to using Project Centennial to package your Windows Desktop app as a UWP app (i.e. driver installation for custom hardware devices is not supported).
Update: Project Centennial based apps can go-live against the Windows 10 Anniversary Update as of August 2, 2016.
A straight UWP + Portable Library code breakout of your app could allow the features of existing Windows Desktop apps to be migrated in a straightforward way to Windows Store / UWP applications.
Note that the main UI layer of your existing Windows Desktop app is not easily converted to UWP.
- WPF XAML is not the same as UWP XAML with differences in control support, touch events, and lack of Triggers in UWP XAML.
- UWP + XAML is a radical departure from WinForms. The headaches you may have encountered going from WinForms to WPF are only magnified in a WinForms to UWP conversion due to no real access to the underlying Win32 API set.
Brokered Windows Runtime Components allow a UWP app to tunnel between the UWP API and the Windows Desktop environment to run full .NET Framework 4.6 code on the Windows Desktop side. The downsides of this approach are many, the most limiting of which is that this technique can only be used on sideloaded UWP apps, not on UWP apps which are meant to be distributed via the Windows Store.
Interesting and non-obvious outcomes I have discovered during Windows Desktop app to UWP app code migrations:
- You discover that there may exist possibilities for your app on Android and iOS with your existing code via third party Portable Libraries and your own code as Portable Libraries running via Xamarin.
- I have found that having UWP compatible code, and Portable Libraries, allows you to create live prototypes that can bring your business services into an augmented reality future on Microsoft’s HoloLens, and a passable default experience on Xbox One.
We are at a true maturity point across the Windows, iOS, and Android ecosystems when it comes to repurposing managed code across all the .NET runtime variants via portable libraries. There is no better time than now to dust off that old-school Windows Desktop code and see how you may be able to put it to great new purposes on modern devices via UWP / .NET Core and/or Xamarin for iOS and Android.
I believe that the great things that Microsoft has shipped via their Universal Windows Platform have been lost in the 5 year sideways journey to catch up to Android and iOS. That sideways journey started with Windows CE variants in the form of Windows Phone 7; through the slight update of Windows Phone 8; the flub of full Windows 8; the long forgotten Windows RT / Windows On ARM strategy; through the full revamp (and necessary stepping stone) that was Windows Phone 8.1; and onto today’s real deal: Windows 10 / Universal Windows Platform.
Microsoft always nails something the third time they take a stab at it. In this case it feels like they have something real with UWP after 5 or 6 stabs and a whole bunch of missteps.
In a recent post to ArsTechnica, Peter Bright, master writer of all things Microsoft, wrote up a concise technical history regarding the path that Microsoft took in order to arrive at the current Universal Windows Platform destination.
With the maturity and solidity of UWP, and the positive mindshare linkage to Windows 10 via marketing and branding schemes, I think it is right to declare that UWP gets Microsoft out of the ‘Bull wandering through a china shop’ phase. With UWP, Microsoft is firmly into ‘We have something that is truly a firm third place contender, and primed for growth’ territory.
Windows Desktop app development has always been a major pain when it comes to:
- Installation and Upgrades — The only clean way to do this was with Windows Installer, and the only clean way to do Windows Installer is Windows Installer XML (just look at that crazy XML schema, and bizarre otherworldly installer object model — Thank goodness for Votive though!)
- COM + Win32 API / PInvoke — No matter what you do, it always seems like you have to resort to COM or Win32 / PInvoke for something.
- Device Access — It seems as if you need to know DIFx to install a driver, then have to know way too much about Windows Driver Model, Bluetooth sockets, or UMDF just to get read and write streams to your device from a program.
- Security — How many times have you seen the ‘Red Banner Dialog of Doom‘ while installing something? Only to be told to click ‘Install this driver anyway’?
To solve the above platform deficiencies, the Windows platform needed a simplified app development model along the lines of Android and iOS. They have that scheme today in the form of UWP, with far superior tooling in Visual Studio 2015, and far easier app coding with C# / XAML.
On previous projects, the primary things holding back any sort of Windows Desktop to Windows Store / UWP migration were:
- Third Party Software Libraries — Tied directly to full .NET Framework 4.x and usable only in Windows Desktop apps.
- Specialized device access (i.e. USB / COM Port / Bluetooth) — Oft times these devices came from third parties as well as an access library written for the device that was only usable on Windows Desktop apps.
The third party software library realm has softened quite a bit. Many third party libraries that were directly tied to full .NET Framework 4.x have been open sourced (allowing you to pull needed bits out), or turned into Portable Libraries for use in UWP (and other mobile platform) applications.
If your existing Windows Desktop app requires integration with devices, you may have some issues with a straight Project Centennial wrap of your app. You may have to adapt and rewrite your device access layers against UWP APIs.
Specialized device access has matured greatly within UWP / Windows Store apps with the release of Windows 10 / UWP. There are now fully supported UWP API sets which allow:
- Bluetooth access
- Standard Serial Port access.
- Custom USB device access (especially true if you used WinUSB for the driver) – Even a good code sample.
A more friendly environment has been created in the world of Windows application development via a series of fortunate events:
- The depths of despair that came with Windows 8 are gone with the rise of Windows 10.
- The purchase of Xamarin by Microsoft.
- Along with the support guarantees and savvy short term moves made since the acquisition.
- Maturity of open source code + flexible licensing of that code
- The rise of the UWP, iOS, and Android compatible Portable Library.
In general, the environment is such that it is a great time to look at a way to fracture and/or pivot your Windows Desktop apps onto UWP, and possibly even iOS and Android via Xamarin. Give it a try, you might be surprised how far your existing old-school code can stretch across modern devices.
Your pivot to get your Windows Desktop application working on Universal Windows Platform may even work on Surface devices from The Next Generation.
Starting on a mobile app can be a daunting proposition.
Your stakeholders at Rex’s Gym really need this app to help drive customer retention, promote the business, and make payments a breeze.
Getting the development environment set up, learning a new language, understanding a wholly different API for screen layouts per-platform, having to go to the Apple Store and buy a Mac (which is the absolutely last thing you thought you would ever do).
Stress, headaches, pain, mayhem, churn! You haven’t even started yet! Then suddenly a manager says that you need:
- Source control
- bug tracking + task tracking
- A reliable build system
- Have all Alpha and Beta builds be installable to any mobile device within the organization
- in-app usage tracking and phone-home crash logging
- push notifications
- OAuth2 based login to existing back-end systems
- in-app payment + in-app recurring subscriptions
- … and to top it off your boss wants an integrated SMS based text message e-mail gathering t-shirt promotion
You go out and look at the Apple, Google, and Microsoft references for all that stuff. Have a slight heart attack after scanning through hundreds of pages of doco. Go home. Have a beer. Lose some sleep. Go for a run. Then you stumble into this blog post that will give you pointers to make all that stuff easier and more reliable than if you had to do it all on your own.
Please note: Where possible I have tried to make service choices that have libraries and connectors that work across iOS (Obj-C / Swift), Android (Java), UWP / Windows 10 / Windows 10 Mobile (C# / XAML), and cross-platform mobile app solutions like Xamarin or Ionic / Cordova. As with all things, your mileage may vary.
Source Control Options – Just use Git, but hosted where?
Source control for projects now has many cloud based options. Most of them also integrate to task tracking and documentation services in diverse ways.
Depending on your preferences and cost profile, there are many awesome options for source code hosting. I have found that the options tend to settle down to 2:
A dark horse here would be to checkout Visual Studio Team System to host your Git repo.
Be sure to check out our other SuperDevelopment article regarding source control best practices for a great overview.
Bug / Task Tracking
For bug / task tracking there are many options. These options may be dependent on choices you make for source control hosting.
If you want industrial strength task management + work items integrated with your source control, then consider Atlassian + Bitbucket + Jira.
I think that the key here is to create an always available, fully transparent, one-stop-shop for all bug and task tracking. Things like e-mail, Slack, and other communication schemes tend to fall apart really quickly when the number of people working on a mobile project is greater than (or even sometimes equal to) 1.
Mobile App Build Server Options
You took the morning and you settled on source control and a good task tracking system. The first task you put in your tracking system is: Setup a build server.
As a corollary to setting up your build server, you would also really like options for continuous integration and continuous builds as you commit changes. You are just one person, and you have 15 stakeholders. The more you can automate, and the more builds you can get out there, the quicker you will solidify the decisions of those 15 stakeholders.
For mobile app build systems + full app CI you have a series of good options:
- Bitrise – A fully cloud hosted build system that lets you snap together your build process. Has integrations to Github and Bitbucket. It even lets you build those pesky iOS projects because they handle a virtual in-the-cloud Mac to handle the Xcode command line stuff. With Bitrise you can be up and running in under a day.
- Jenkins – An on premise solution. Only tackle this if you have a spare Mac laying around. Could take 4-5 days to rev up Jenkins and make it reliable. Plus ongoing maintenance. Overhead is worth it if need a fully on site solution.
- The recent shipment of Blue Ocean by the Jenkins team really starts to make the Jenkins build system look like a great option.
- Visual Studio Team System — If you have Microsoft Azure credits, then take a serious look at VSTS for mobile app building.
Special Note: Fastlane Toolset
You start revving up your builds, and start to notice some badness: The Apple Developer Portal has all these crazy requirements for certificates, provisioning profiles, app IDs, Ad-Hoc provision, App Store provision … Arrrgh!
Fastlane also solves many other problems:
- Pilot – Command line publishing of your iOS builds to iTunes Connect / TestFlight
- Snapshot – Creates localized screenshots of your app which you can use for per-country app submission to the Apple App Store.
- … and so much more.
To document all the greatness that is Fastlane would take hundreds of pages. Suffice it to say, relax, lean back, and learn to love Fastlane.
Alpha / Beta Build Distribution – HockeyApp
While revving up your build system, you took a look at your next line item: Easy distribution of Alpha and Beta builds to any mobile device, usage tracking, and phone-home crash logs. In this realm, I really recommend:
- HockeyApp – It really does it all.
- Easy integration path as an app binary output destination with all of the above build systems.
- On-device app which creates a mini-app store for distribution of your Alpha and Beta builds to your internal customers.
- Easily integrated usage tracking and crash log reporting API for iOS, Android, Windows, and Xamarin based applications.
- You can even use all the usage tracking and crash log reporting for your shipping application, not just for Alpha and Beta builds.
Other app tracking services are out there, but the ‘one stop shop’ of HockeyApp, in addition to Microsoft backing the product, makes HockeyApp a very slick solution especially if you are in a hurry.
It has been a couple of days, and you have all your build infrastructure revved up. Your initial Xcode project is up in Git source control, the app is building automatically on every commit / push via Bitrise, all that provisioning profile / certificate stuff is on auto-pilot with Fastlane – match, and you even have your first ad-hoc build installing to your personal iPhone via the HockeyApp app. All is right with the world.
Now you tackle a couple of screens from your requirements, and meet your first sprint deliverable. Your stakeholders are amazed that you were able to deliver the app to their specific devices after only 2 weeks.
The new sprint comes up, and you look at some of those bigger items on that task list. The next task you know you need to tackle is push notifications.
Push Notifications – Urban Airship
IMHO the first place to go is Urban Airship.
There are other services out there, but nothing scales out and up with your business messaging needs quite like Urban Airship does.
In my experience, I was able to hand over a restricted role based login from Urban Airship to my primary stakeholders and watch as they created and sent push notifications out to the app with ease.
Urban Airship’s per-platform integration options are second-to-none as far as ease of app integration.
Everything may depend on your cost requirements especially as it relates to projected number of users and needed level of messaging.
It took a couple of days, but you now have Urban Airship integrated, a development messaging environment is now delivering push notifications to your app, and you are ready to tackle the next item.
Alternatives to Urban Airship for push notification handling include:
In-app OAuth2 Login
The customers login to the current web site using a series of web based OAuth2 login schemes against a custom back-end server. Your app has to integrate into those same login schemes. Even worse: They also want you to be able to handle login via Facebook, Google+, and Twitter.
Just to pile on, your stakeholders demand that you find a way to not ‘just embed a web view’ to do the primary OAuth2 based user login. It’s OK, they might understand you have to show a web view for Facebook, Google+, Twitter, and other social network pairing but they don’t want to see a web view for the primary app login. As much as possible your stakeholders want pure native views for all logins.
There are frameworks out there to help you do this, but they can seem scattered and hard to integrate per mobile platform per social network. Windows 10 / UWP especially seems very complicated as far as doing a native OAuth2 based login, getting back the user roles by cracking open a secure JWT, all without a web view.
There is a third-party service that may be able to help. In this case the service is Auth0 (pronounced Auth Zero). Auth0 provides a wrapper / helper depending on server login type as well as a full suite of per-mobile platform front end login API connectors.
The mobile app integration for Auth0 divides into 2 general schemes:
- Lock — Auth0 presents all needed views, web views, and other login UI for you.
- Client API — Allows you to code a fully native UI yourself and just passthrough username / password and other login configuration parameters via a pure API.
Worthy mention: Amazon Cognito.
You are about 3-4 weeks in so far. You have major app screens up. Your boss loves the notifications, she even gets them on her Apple Watch. Your product managers are floored at the awesome login integration. You have already forgotten about all that build / signing / provisioning / app distribution stuff because all you do is commit, and the build pops out of HockeyApp automagically and installs to your internal test and stakeholder devices.
Well there was that whole crazy Ad-Hoc build headache with adding UDIDs of the designer’s main devices but Fastlane made that easy via register_devices …
In-app Payment + In-app Subscription
Your stakeholders are getting itchy. They want $. They want to make sure that you are looking at in-app payment and in-app subscription schemes. Next sprint comes around, and you start to look around at options (I mean, you need to get $ too, right?).
Your business doesn’t have a payment system in place that you can easily integrate with. You start to sweat a little. Until you find Braintree Payments.
You look at the Braintree client list and realize that you have bought stuff through them and never even realized it.
You sign up for their sandbox. Do some preliminary app integration. The stakeholders are kinda ‘Meh.’ when it comes to a few issues. Then you go for the throat and show an in-app Apple Pay integration with your sandbox. That demo just showed you buying a recurring membership to Rex’s Gym with your thumbprint. How is that not made of pure awesome!
You also looked around and found out that Urban Airship has a similar system.
T-shirt e-mail gathering promotion?
You pop your head up at 6PM on a Friday after an all day coding frenzy, go get a Diet Mountain Dew. Close your eyes. Stretch. Open your eyes. Wha… your product manager is dangling a t-shirt in front of your face.
It is a cool t-shirt. You are working for Rex’s Gym and the design is awesome.
Your product manager says she wants you to fully engineer a t-shirt promotion from within the app. The end user is going to text their e-mail address via SMS to a phone number, it is your job to receive the text, process the e-mail address out of the text, and send out an invite e-mail from Printfection that allows the user to get their t-shirt.
She hands you the number that receives the SMS messages, and the Printfection credentials, and tells you go get it done.
So you look around and realize that Printfection has an API. But the last thing you want to do is code up a whole bunch of the stuff in the app, or even on a hosted server, to hit that API and manage the whole workflow of this promotion.
It is 6PM. It is Friday. Code haze has entered your brain from the all day binge. A sunny weekend awaits you! Help!
So you look around some more and find Zapier.
Zapier lets you setup a ‘zap’ that fully automates the whole flow:
- SMS is received
- Scan SMS for e-mail address
- Log e-mail address in a Google Sheet
- Send Printfection invite to e-mail address.
… all of that with no code to create, maintain, or host.
Special thanks to Ben Peter of Zapier for his presentation at minnebar 11 for this one!
Azure – iOS Developer Center – Can handle push notifications, single sign-on, and many other data handling scenarios.
Firebase – Owned by Google. Handles many back-end services, including push notifications, usage tracking / diagnostics, and much more.
In this era of travel budget crackdowns and higher than normal oversight into technology budgets, the iOS software engineer can get lost in the shuffle when it comes to training time and opportunities to talk with other members of the iOS development community.
Due to the rise of the popularity of Apple’s iOS platform, Apple WWDC (Worldwide Developer Conference) has become the central rallying point for iOS developers. It seems that the entire iOS community gathers in San Francisco over the week of WWDC. Many developers go to San Francisco over the week of WWDC even if they don’t have a ticket to the conference.
A ticket to WWDC costs $1599. Since 2014 you only get to purchase a ticket if you get picked during the lottery phase of enrollment. In my opinion, this is a very fair system considering the high number of developers who wish to attend.
Due to the high number of people going out to San Francisco over WWDC week, the hotel prices during WWDC week have almost tripled since 2011. John Siracusa, of Mac OS X Review and Accidental Tech Podcast fame, has equated a night of sleep in a hotel during WWDC as $ equivalent to an Apple Watch. You sleep 1 day, that’s 1 Apple Watch (Sport). You sleep 2 days, that’s 2 Apple Watches… From Sunday through Friday you may have to plan on spending $1600 just to sleep.
The airfare remains affordable. Well, as affordable as airfare can be from your home location to SFO.
Before you have so much as sipped even one $7 Blue Bottle coffee (totally worth it, just do it!), the conference has already cost around $5000 dollars.
To a cost conscious manager $5K as a baseline price for a week spent at a conference can seem like a pretty steep price to pay.
I would submit that the $5K cost is a really good value if you know how to attack WWDC.
- WWDC is not anything like Microsoft Build.
- You get insight into the hierarchy at Apple that you can’t get anywhere else. Especially the relationship between you (the developer), the Apple Evangelist, and the Apple Engineer.
- The all-day technology-specific labs that Apple runs at WWDC may be the only way you are ever going to get face time with Apple personnel that have specific knowledge in your app subject area.
- You get inspiration and insight from the special lunch sessions.
- You can take advantage of the 1 to 5 ratio of Apple personnel to attendees.
- You agree to a Non-Disclosure Agreement regarding session content. This turns out to be a great thing because you get exposed to stuff that you never experience otherwise.
- There is now plenty of good content presented at other nearby venues at the same time as WWDC.
- You can also usually see Jim Dalrymple at The Chieftain (Get the Fish n’ Chips!)
- John Gruber of Daring Fireball fame has another event planned for WWDC 2016. His WWDC 2015 event was not to be missed as he had Phil Schiller from Apple in an on-stage interview.
- Apple even let’s attendees know of other events that are in San Francisco during WWDC week.
- WWDCGirls – A Women at WWDC lunch and networking event.
- Sometimes you are at the epicenter of a major shift in Apple’s technology stack.
- Those who attended WWDC 2014 got the boost of being at the center of the Swift rollout. The Swift rollout surprised most Apple employees, not to mention many attendees.
Note: During this blog post you may notice that I am being completely vague and only giving you an impression or insight with no detail. When you attend WWDC you agree to a Non-Disclosure Agreement. This means that you can’t talk about details or technical information related to content presented there. Because of this, I can only give you my impressions of my experience at WWDC. This NDA has loosened in recent years, but I think it is still good to keep the attitude: ‘What happens at WWDC, stays at WWDC’.
WWDC – General Structure
WWDC starts with a day 1 keynote. This is a classic Apple keynote.
The keynote is usually at 10AM Pacific Time.
For WWDC attendees who want to be ‘in the room’ this means that you may have to line up at about 7AM. You are let in the building around 8:30AM. Then you wait. For almost an hour and a half. In a hallway with no chairs.
They open the doors to the main keynote area, everyone finds a seat, and the keynote begins.
The keynote ends about an hour later. Everybody leaves for lunch. Then the remainder of the first day is spent on a more engineering focused deep dive set of talks called ‘State of the Union’.
The rest of the week has standard conference tracks scattered around the many rooms all grouped by technology.
Many of the sessions are repeats of sessions from previous years with a little more content added and/or clarified.
I am pretty sure I am not divulging too much info here as all of these sessions and the schedule are available via the WWDC app.
WWDC != Microsoft Build
In order to really ‘grok’ how Apple’s WWDC is dramatically different from other technology conferences you really need to attend. I have been extremely fortunate in that I have been at 2 WWDCs and a series of Microsoft conferences. I would also point out that the WWDC differences also show how Apple is a dramatically different company (especially from Microsoft).
Apple WWDC is dramatically different from Microsoft conferences in so many ways.
- Degree of Preparation
- WWDC is highly polished. Every session. All the time. It feels like all the session speakers have rehearsed their material for weeks. It feels like all the presented material in all the sessions has been vetted by the Evangelist (and possibly marketing) hierarchy at Apple.
- Microsoft Build has well polished keynotes, but the per-session material can feel a little ‘slap dash’. In this way Microsoft Build sessions feel more genuine but aren’t as watchable as Apple WWDC sessions.
- Contrary to the initial impression you may get, WWDC is fairly open. It is more open once you understand the role of the Apple Evangelist as a gatekeeper. Do not try to get the time or attention of a presenter at a given session. Go to the labs. The labs are largely a free zone where engineering conversations flow freely between attendees, Evangelists, and Apple engineers.
- Apple presenters do not usually hand out their e-mail or contact information as their public exposure seems closely regulated by the Evangelists.
- Microsoft Build is completely open with engineers and members of the Microsoft hierarchy handing out Twitter handles and work e-mail addresses.
- Contrary to the initial impression you may get, WWDC is fairly open. It is more open once you understand the role of the Apple Evangelist as a gatekeeper. Do not try to get the time or attention of a presenter at a given session. Go to the labs. The labs are largely a free zone where engineering conversations flow freely between attendees, Evangelists, and Apple engineers.
Insight into hierarchy and roles – You, Apple Evangelist, Apple Engineer
The Apple WWDC session structure is very rigid. If you analyze a series of Apple WWDC session videos you start to notice this rigid structure:
- Speaker shows title slide of session with their name on it for about 5-15 seconds. — No e-mail address, Twitter handle, or other contact info of the engineer will appear on the slides.
- Note: Sometimes the presenter exposes some contact info, but it is incredibly rare.
- Speaker proceeds through their material.
- Last slide shows links to online Apple SDKs, additional WWDC sessions, and the name of an Evangelist for the technology stack that the session was about
- If the session has a Q&A you will notice that the Evangelist does triage of incoming questions from WWDC attendees. The Evangelist will usually do their best to answer the incoming question, frame the scope of the answer, then will either trust an engineer to answer on stage or redirect you to a lab time to talk more.
The well coordinated Developer to Evangelist to Apple Engineer communication path is unique. The role of Evangelists as gatekeepers to the time and energy of the Apple Engineer leaks through in almost every session you attend at WWDC. Once you understand the rules of the Apple hierarchy in regards to exposure of Apple engineer face time to the developer community, you are now ready to head into the lab spaces at WWDC get your questions answered and have great conversations with Apple personnel.
The Labs are invaluable
The per-technology lab areas at WWDC are invaluable. If you have had electronic contact with an Apple engineer at any time the previous year, you should be able to get face to face contact with that engineer in a lab space. WWDC is, most likely, the only time that you will ever get real face time with an Apple engineer throughout the year.
If you are signed up for any of Apple’s side programs (i.e. Made for iPhone/iPod [MFi], AirPrint, …) then the labs are the one safe space for you to talk engineering specifics in and around that program. The NDAs you sign in order to participate in those programs may largely preclude you from even talking with your peers about what you are really working on. At the specific lab times, and only at WWDC, can you get one-on-one time to talk about the proprietary NDA’d specifics of your application.
When I was at WWDC 2010 there was mention of a series of technologies during the keynote that seemed to overlap with a non-Apple project I was working on. I went down to the labs to talk with Apple people about their project, and related my experience on my non-Apple project. From that experience I gained a ton of insight and validation regarding my project that I never would have received otherwise.
Go to the lunch sessions – They are the hidden gem of WWDC
You just spent a whole morning attending hard technology sessions. You have a numb brain. You have some messages and work to catch up on. A lunch to get eaten. The last thing you may want to do is go to a session over lunch.
The WWDC lunch sessions are where Apple invites people from outside of the company to come in and share how they are applying a specific technology stack to a given creative problem. Every lunch session I have attended have been the best sessions I have attended at any conference. The speakers are engaging, the content is insightful and inspirational. Don’t miss the lunch sessions.
There is a 1 to 5 ratio of Apple personnel to attendees
This is one of those stats that I heard then just kind of dismissed. I mean: How could I ever possibly be able to pick out Apple personnel from the 5,000 other attendees at the conference?
It turns out that Apple gives employees specially colored badges which stand out. In addition, most of the Apple employees wear an ‘Apple Store’ like t-shirt. You do end up seeing and talking to quite a few Apple employees. Many Apple employees seek out and engage with developers at WWDC because that is one of the very few times that they can engage with the developer community.
Over breakfast one morning I had struck up a conversation with another engineer about App Store policies. An Apple employee responsible for App Store policies, and some of the technology, overheard our conversation and joined in. The conversation that was sparked was great. In this case the Apple employee had a series of questions that he asked, and largely listened as we talked about a series of things. The feedback we got was invaluable regarding how and why Apple has the App Store policies that they have.
At each session there is a roped off area at the entrance: One side where Apple employees line up, the other side where non-Apple employees line up. All non-Apple employed attendees get into the session first, then the Apple employees get any remaining seats.
I mention this because when you combine the waiting lines in front of a session with the specially colored badges + t-shirts you can get insight into which sessions may be the most interesting. You get immediate visual feedback for what the Apple engineers think the most important technology topics are just by looking down a wide conference room hallway and looking for clusters of colored t-shirts.
Way back in 2011 I was at WWDC and I was waffling between 3 different sessions being held at the same time. One was about Bonjour networking, one was about Xcode enhancements, and one was really out there (for me at least): LLVM / Clang compiler futures. I walked past the networking and Xcode enhancement sessions and there were people in line, but only 1 or 2 Apple employees. Then I went past the LLVM / Clang compiler futures session, the line of Apple employees waiting to get in was down the hallway and had practically turned the corner. I immediately ducked into that LLVM / Clang compiler futures talk.
Non-Disclosure Agreement – Not a bad thing
I hope that I am allowed to tell the above story, because you sign an NDA that states that you cannot talk about any session content from WWDC. This actually turns out to be a good thing.
Apple has relaxed the NDA in recent years. However, that NDA still applies for some sessions, labs, and conversations that you have with Apple employees. If you are under NDA for other Apple programs, then those NDAs are fully binding in the lab areas as well. You may be asked by an Apple employee in a lab area if you are under NDA before they can talk about certain technologies.
I can’t get specific, because I signed an NDA when I attended WWDC 2011, but I think I can dance around enough stuff to give you insight into why that NDA was a good thing.
Over lunch Apple has special sessions given by people from other companies that highlight how they use certain Apple technologies. These special sessions are skewed way more to practical application of technologies for specific businesses or creative endeavors.
At one lunch session we were able to see unreleased creative content, as well as how technology enabled that content to be created. The speaker stated outright that without the NDA we agreed to at the beginning of WWDC that there was no way his management would have allowed him to show this special content and inside info during his presentation.
In Captain America: Civil War we get to see the ultimate battle between Iron Man and Captain America.
It is a battle of simple gutty defense vs. smart weapons and flashy offense, humility vs. brashness, down in the dirt vs. up in the clouds.
To totally geek it up, the same kind of battle exists in the languages that software engineers use today and I believe this is especially true in the battle of C# vs. Swift.
Don’t worry, this really isn’t a versus type write up. If anything I seek to point out each language’s unique strengths, then show how software engineers can get into the right superhero mindset to really use those strengths, and be aware of the weaknesses, to create great solutions.
C# = Iron Man – Strong Flashy Offense
C# is truly the Iron Man in this comparison. It is amazing how much showy weaponry C# can bring to bear to solve problems.
- Have a problem with your UI freezing up? Bring in Task<T> / async – await, and seamlessly refactor years old code to be fully asynchronous, even within native UIs where thread synchronization is key.
- Have a super large dataset that you need to tame? Bring in IEnumerable<T> / yield return or Lazy<T> from the deferred execution realm.
- Have a need to produce arrays and collections that are the result of super smart functional filtering? Bring in LINQ.
- Need to do smart filtering of XML? Bring XDocument and its magic LINQ over XML powers.
- Need to do JSON processing? Head on over to NuGet, reference Newtonsoft.JSON ,and get stable, powerful JSON serialize / deserialize behavior and be done in no time.
- Need to hit a REST service with super specific HTTP header formatting and authentication? System.Net.Http has you covered.
- Need a cross-platform way to retrieve data from remote sites + Model / View / View Model architecture? Check out ReactiveUI.
- Need async but inline immediate responses to collection changes? Check out Rx.NET.
- C# is strongly typed, but you can also use reflection and loosen that strong typing as needed.
- C# can even be used to generate itself.
There is every gadget and gizmo that you can bring in and bolt on to existing C# code to get your job done. Even the very oldest C# code from 2002 is still supported and easily transformed using Visual Studio, or Resharper tooling into something shiny and modern.
C# has all these weapons, but the lifetime of these weapons are sometimes mere seconds before they are replaced with the next version via NuGet. The masters of C#, just like Tony Stark, have no issue with throwing out just created stuff in favor of the next great thing.
C#’s weaknesses are the dreaded NullReferenceException and the indeterminate mutability of most data structures. C# is great at attacking problems, and hitting at the 90% of the solution in a lightning quick way. However, C# doesn’t play defense very well. If you go too fast too far with C# you can out run your air cover, leaving you vulnerable when attacked from the flanks by null members, timeout errors, weird data changes, unhandled exceptions, or not connected to network scenarios.
C# is a highly flexible, multi-weapon language that you can use to attack any problem.
Swift = Captain America – Strong Defense
Swift is the ultimate boots-on-the-ground and in-the-mud defensive language. In Swift you don’t solve problems by attacking them head on with whole armories of shiny weaponry, you hunker down, put your shield up, and start slogging up that hill one step at a time.
Every line of Swift code written requires the author to think of the worst case:
The inventors of Swift must have looked at the metrics of existing Objective-C iOS applications and realized that the number 1 and 2 problems were:
- Coders not realizing that the data they are changing on one screen leads to changes in data on other screens.
- App crashes due to trying to access the value behind a null pointer.
Defense was needed. The power of Captain America’s vibranium shield was needed, only this time wielded by coders to stop these major in-app issues.
Coding in Swift is highly defensive in nature. To see this in action take a look at Swift Optionals, if .. let syntax, and the class initialization rules. As you use them, Swift optionals will permeate your entire thinking as you rev up your data structures. Every variable you use and/or create needs to be immediately thought of in terms of optional vs. non-optional.
Within Swift the use of specific reference and value types allows you to defend against unwanted mutation to your data structures.
Each line of defensive code is one more brick piled on top of other bricks of defensive code. When done you end up with applications that resemble the Great Wall of China and are truly written for the worst case. This layered defensive code coordination leads to super solid software structure that can take a real beating when attacked by the invaders (or users) of the software.
When done solving the problem in Swift you have a beautiful shiny shield that can repulse almost any mutability or null data attack. Because you play so much defense in Swift, coding up solutions to things seems to take longer. In reality, you have taken all that defense that C# out ran and have incorporated it into the structure of the solution.
The constant nullability slog, coupled with the constant mutability slog, while coding in Swift leads the developer to wanting more weapons to go at problems. Constant defensive coding slog can lead to developer fatigue quite quickly. However, when the problem solution is achieved, the engineer can see that their defensive coding effort has been like using Captain America’s shield as their primary weapon.
With the future potential of Swift existing across platforms, it could mean more solidly crafted software across the board, from server side to mobile applications. The underlying thought process behind Swift is already starting to leak into other languages, especially in the area of nullability.
I know that Swift isn’t without its share of flashy bolt-on weapon systems. Comparing C# to Swift when it comes to third-party library support is like comparing Iron Man’s crazy spin laser and hand repulsors to any weapon Captain America has ever wielded (at least in the movies).
But who wins in the ultimate battle?
If you ask me, I think Captain America and Iron Man are both good guys who should be augmenting each other’s strengths and covering their corresponding weaknesses. I bet the *SPOILER* real big bad *SPOILER* is hiding behind the scenes and making them battle it out.
As with all things in software engineering there is never a clear winner. There are drawbacks and advantages to the structure, approach, and capabilities of all languages and constructs. These drawbacks and advantages tend to fit or not fit for solutions to given problems.
Good ideas tend to bubble to the top (i.e. delayed execution, in-language async, nullability enforcement, mutability enforcement), whereas bad ideas tend to settle to the bottom (i.e. garbage collection in Objective-C).
Swift is so new, the in-language concepts so hardened, the community so outspoken and willing to move quickly, that the verdict is not yet out.
C# has been around so long, has so much weaponry, and is currently so incredibly flexible across even dynamic and functional concepts. There is no way C# doesn’t continue to flex with some of the core concepts surfacing from the Swift and Kotlin worlds.
Who knows, one day you just might see Iron Man wielding Captain America’s shield. Just like C# currently wields dynamic and functional constructs, C# could well start to take on deep nullability constructs as they exist in Swift.
At the end of the day, we all win as these 2 languages battle, take on, and wield the best parts of each other to surface great solutions to real software problems.
Previously we have looked at the basic configuration of SystemJS and what happens when you attempt to load modules. What we have covered so far is good enough for a development system, but things are different when you try to push your code to production and performance is much more important. It might be fine for a development system to make XHR requests for each individual script file, but that is not ideal for most production systems. This article will attempt to evaluate the production setup that is needed to attain good performance. [Read more…]
I am amazed that content of this quality was presented by community members for free. It was totally worth being inside and roaming the maze-like halls of Best Buy Corporate Headquarters on one of the few sunny Saturdays we get up here in the frozen tundra of Minnesota. The exposure to new technical topics was great, but more importantly experiencing the energy of the people who are active in the Minnesota tech community was the real core of the experience.
I will try to mirror the energy and great themes of each of the sessions that I attended. The keyword is ‘try’. I apologize in advance if the energy and competence of each session I attended doesn’t shine through. Hopefully, some of the links I am adding to each session will help you navigate to additional resources.
This session consisted of a panel of people active in the Minnesota startup community.
- Jeff Pesek – Moderator from tech.mn a news site dedicated to the startup community within Minnesota.
- Glafira Marcon – Lead organizer of Healthcare.mn
- Dan Atkins – Co-founder of MinneAnalytics
- Ryan Broshar – Techstars and Matchstick Ventures
- Justin Grammens – Co-founder of IoTFuse
- Kevin Spanbauer – Dedicated to finding and providing resources and people to software startups within Minnesota
The general takeaways that I got from the panel were:
- Get involved with the community
- Don’t be afraid to share your ideas. Sharing your idea will only make it stronger.
- Double down when it seems like you should quit, double down again when it seems like you should stop, and when it gets hard and you think you are truly at the end, double down again
- There is help for anything you want to do with your startup. From business, to community, to technology, there is an amazing community here in Minnesota that is dedicated to helping you get your business started in some way.
- In general the panel is encouraged at the state of the startup and general business climate in Minnesota.
- The depth of participation in the MN Cup Startup Competition was cited as a great sign of the vitality of the startup community within Minnesota.
The process and overall maturity of the way in which the U of M incubates and manages the movement of their technology portfolio from the university into the business sector is astounding.
I can’t do the whole presentation justice, but for future reference you should watch the U of M Entrepreneurs site. Especially great is the University Startup Pipeline Google Doc which shows the stages of the startups as they move from the university onto business.
Ben Peter gave a great presentation on how to use the Zapier service to create custom data workflows from existing third party Web APIs.
His best demo was a code-free custom workflow that would send a free t-shirt to an attendee given an e-mail address contained in a text message. The demo used Zapier to aggregate SMS, Google Sheets, and Printfection, all without code to create a custom business promotion on-the-fly.
There is real power in being able to aggregate the features of entire businesses via their API surface. This power allows startups to create easy solutions for repetitive business tasks in a fraction of the time and resources of having to write custom code or rev up whole hosts and custom service silos.
Andrew Rahn of Iconfactory gave a great side by side talk that compared Kotlin and Swift.
I really enjoyed his openness, energy, and passion for this topic. His openness really made the talk a true two-way discussion between himself and the audience.
Personally, I have done some Swift, and absolutely no Kotlin. His session served as a great jump start for me as I learn more about the Kotlin language.
The general take aways were:
- Both Swift and Kotlin are really new languages, and as such are in a state of flux as their owners tweak the compilers, syntax, and environments
- Both Swift and Kotlin are modern languages that force the developer to use the compiler to check nullability and mutability rules
- Swift and Kotlin suffer greatly from being bolted on top of their respective legacy heritage (Swift — CocoaTouch / Objective-C / Automatic Reference Counting — Kotlin – Java / Android)
- I would be incredibly lucky to ever get a chance to work with Andrew Rahn on any project.
I went out of my comfort zone of front-end UI development and attended this panel.
Please see the minnebar session page for the panel members and full description of the session.
- When it comes to data science you spend over 90% of your time cleaning up your data sets before you can actually do any analysis. Things like different date formats, missing or null values, punctuation, and differing data entry techniques cause the data scientist to spend a ton of time cleaning up data.
- There is a debate within the data science community between those who are going hunting through data looking for patterns, and more hard science statisticians who seek to apply statistical techniques to data to achieve a less biased / less ‘hunt and peck’ methodology to looking at mass data sets.
- The Analyze This! competition seems like a really great thing to take a look at. The Analyze This competition is a long term (3+ months) competition that goes from raw data through to creating a possible predictive model.
- Another interesting resource that was mentioned was Kaggle. Kaggle is a source of competitions and sample datasets.
At heart I am a native front-end developer, and this talk was 100% in my wheelhouse.
Their work brings the architectural ideas of React and the concepts in Flux to front-end iOS development using Swift.
Their presentation was done so well that the core concepts they presented could be applied to clean up and simplify almost any front-end development you may be doing on any platform.
Their work has inspired me to start pursuing a similar framework for Xamarin.iOS and Mono.Android development. In fact, the more I think about, the more I realize that their work may be more powerful when expressed in a cross-platform framework as it could lead to incredibly thick UI code sharing between platforms, and incredibly thin per-platform code. The possibilities for eliminating MVCs (Massive View Controllers) or huge overwrought Android Activity code are awesome.
If you do any UI work at all on any platform: Run, don’t walk, to their presentation slides and see the future.
Justin had some great examples of applying the Google Prediction API against the Nice Ride data set to try and predict where a bike would be dropped off depending on when and where it was picked up.
The main question from the audience during Justin’s demos was: What is the underlying statistical model that the Google Prediction API uses? The answer, unfortunately, is that Google isn’t telling.
I would file the Google Prediction API away as a future tool for your toolbelt. At least until Google takes it away, never to be seen again.
In the last article we took a look at some of the basic configuration options of SystemJS and also the high level workflow of what happens when you attempt to import a module. This article is going to walk through what happens from when a script has been fetched by the browser until a module instance is returned, as well as provide some information on creating plugins for SystemJS. [Read more…]
HATEOAS stands for “Hypermedia as the Engine of Application State” and it is one of the possible constraints that you can place on a REST compliant API. Essentially what it means is that your API is as navigable as a normal website, with hyperlinks leading to other resources. The focus of this blog is not HATEOAS itself – instead focusing on an implementation of it our team recently used for our project’s API.