I didn't expect to write a follow up to my post on architecture, organization, and ownership so soon, but I had a new use case come up that I couldn't pass up discussing. Here's a story of how we architected a set of infrastructure not just to ensure delivery and best practices, but also to ensure that maintainability was as simple as possible for the responsible team.

A few months ago I was faced with an architectural question from a team I was helping with their cloud deployments. They were developing a data processing solution that wanted to hook into a shared S3 bucket, owned by another team, which was already integrated into its own system. We deployed a decentralized solution to Production and it worked smoothly. That is, until a few weeks later when the notifications suddenly stopped flowing. The investigation and resolution of this issue revealed a lot about the architecture and the organization that influenced it.

As applications grow more and more complex, they may have to call an increasing number of external web APIs. As we build more features, we may depend on servies that we do not control, for the sake of gaining functionality we wouldn't be able to implement ourselves. That's great! What's not so great is when one of those services goes down, or has a major breaking change, or goes away altogether. Then, if we have not planned correctly, we may completely break our app with no immediate fix available. This is why I propose that to retain complete control over user experience, it is important that we maintain complete control over every external web call that goes in and out of our app.

As a result of reading many blog posts and watching many videos from the iOS developer community on app architecture over the past year, I grew incredibly dissatisfied with the bloat and complexity of my app's typical MVC architecture. I did some research into some alternatives such as MVVM but was also unimpressed with the complexity that came with them. For example, the ideal way to implement MVVM is by using functional reactive programming, which introduces a completely different programming paradigm with a steep learning curve. But then I found a new pattern for architecting apps, which was a dramatic change from traditional MVC, yet very familiar. This pattern is called the App Coordinator pattern.

I write this in mid-April of 2016, just 3 short months from this year's edition of Apple's Worldwide Developers Conference (WWDC). This year's conference is slated to preview all-new, feature packed releases of Apple's operating systems (iOS 10, OS X 10.12, watchOS 3, and tvOS 10). As such, there are already rumors and wish lists for what people want to see from this year's WWDC announcements. Allow me to throw in my two cents.

When Parse out of nowhere announced its yearlong shutdown process on January 28, many developers were left in shock. The backend-as-a-service has been used by thousands upon thousands of apps to enhance their backend capabilities without having to maintain said backend themselves. Everyone was caught by surprise, and are now rushing to migrate their data and services elsewhere. That being the case, only good news that can come of this is the plethora of options of where to go from here.

I had to deal with errors a while back whose troubleshooting strategy was to run pod install, clean the project, and nuke the derived data. Everything seemed fine after that, until I wanted to work on a different branch. It seemed that every time I switched branches the same errors would pop up, and I would have to repeat the same process to fix it. It soon became very tedious to have to fix these errors every single time I switched a branch. So I thought, Why not automate this process on branch switch? So I did.

A lot of us probably use at least one of Google's public data APIs. It's unavoidable. From YouTube to Google+ to even the URL Shortener, it is inevitable that we will use one of Google's APIs because they are so useful. Those of us using Cocoa and Cocoa Touch to access those APIs are directed by the APIs' documentation to the open-source Google APIs Objective-C Client for implementation help. But now it's out of date, and Google hasn't done anything about it.

The WWDC 2015 keynote has come and gone. There were great announcements, from iOS 9 and OS X El Capitan, to watchOS 2 and even the unified Developer Program. I am not here to talk about any of those announcements; I'm here to talk about Swift.

Although Apple has taken great strides to optimize its frameworks for Swift, they haven't quite gotten there yet because they've also had to support Objective-C. As well, all of Apple's frameworks are *written* in Objective-C! Wouldn't life be so much better if there was a wrapper for the Apple frameworks in Swift that takes advantage of some of the niceties of the language that annoy us the most in the interop-from-Objective-C transition, plus some extras? I'd say so!

So with the new Swift programming language came a whole lot of improvements to the development workflow. It also came with a lot of headaches, of which I will demonstrate right now.

Facebook recently held their developer conference, F8, in San Francisco. Their focus this year was making changes so that developers would further take advantage of their platform. They didn't launch some new consumer product like they've done other years. This year's focus was on developers.

Because Call2Disciple has an online store that is an integral part of their business, I thought it was wise to look into ways to be able to purchase physical goods via an avenue other than In-App Purchase for its iOS app...