magsafe

Thank you, you bring up some excellent points.

One thing I didn't see mentioned in this article is Firebase. It feels like a hidden gem lurking within the overall GCP offering, and may be overlooked by devs who're not doing mobile-specific work. For me, Firebase was the gateway drug that got me into GCP. I successfully built and hosted the backends for a couple of iOS apps using Firebase. The best parts were cloud functions and built-in sync (including offline/occasionally connected sync scenarios). Firebase Cloud functions allowed me to convert an AWS Elastic Beanstalk project into a 100% serverless architecture, which basically runs itself with no ongoing maintenance or scaling required. It took a significant amount of work off my shoulders. Once I had a positive experience with Firebase, I started poking deeper into the Cloud Console. I realized I could use App Engine, Compute Engine and various other services, which all made perfect sense as "upgrades" to the core Firebase project. I've now migrated the backends of 2 existing, popular iOS apps from AWS to Firebase+GCP. Kudos to the Google team for making Firebase perfect for my needs, and the overall Cloud platform.

Does AWS offer something similar?

https://www.bottomlinehq.com Single founder/employee, 6-digit revenue, no outside funding.

Can this be used in React Native apps?

I'm a full-time iOS developer and want to share my perspective on this news. The developers who create those amazing apps on iOS are not going to fall for this. I'm one of those developers, who pays very close attention to detail to make pixel perfect apps that I'm proud to put my signature on. I will not accept my brand being introduced on Windows or any other platform using a glorified code generator. If I want to bring an app to Windows, I would learn the platform, go "all in" and make my app as perfect on Windows as it is on iOS. This would require me to dig into all the SDK docs, understand the platform capabilities, learn the native APIs, deal with the challenges of supporting different form factors, and a lot more. There is simply no shortcut to a great app, and a developer who is proud of his app would not release something that a machine generates. A great app is not one that has been thrown together using abstracted APIs and a code generator. A great app is one in which the developer has written and/or analyzed every line of code to maximize the aesthetics and performance on the platform it is running on. Windows' code conversion isn't going to encourage the really good apps to migrate, although it might entice some cheap knockoffs or poorly designed apps to ship an equally poorly designed experience on Windows. So bottomline, I don't expect apps like Instagram to suddenly appear on Windows because of this.

Also, developers don't avoid Windows because it lacked a code conversion tool. If all it involved was learning a new language or porting some code, developers would do it, just like they learned to go from Objective C to Swift, or all the evolution of Cocoa Touch through the years.

Developers avoid Windows for far more complex, intangible reasons that go way beyond a code converter. There are all kinds of perceptions about Windows and Windows users that simply will not change because of this tool. The iOS developers I know will shrug off this announcement, and continue shipping their apps on iOS. I admire Microsoft for overcoming the technical challenges of creating this tool, but sadly they have not overcome the perception and mindset challenges of a dieing platform.

Am I the only one that considers lunch to be a sacred, personal time that I don't want to spend on small talk with coworkers? I need my lunch break to recover from the day's stress and pace, so I can come back refreshed and ready to code for 4-5 more hours. As an introvert, I find the team lunches to be waay more stressful than actual work, and that eliminates any benefits of a nicely cooked meal. If I end up in a team lunch situation, I find it hard to be productive for the rest of the day (unless I take a separate mini-lunch break by myself later).

The situation was especially bad at one recent job where the lunch conversations always revolved around local sports, which I had no interest in, or this guy remodeling his house, which was only interesting the first 3 times he gave us an update. So I started bringing sandwiches to work, parking in the garage beneath the building, and eating lunch all alone in my car in the dark, listening to NPR or just enjoying the silence. It was the most refreshing hour of my workday and I felt 200% more productive after that break than I would after 30 minutes of small talk about sports.

I just want to point this out to people who think team lunches should be mandatory. Not everyone enjoys them equally, and it's not always just about the food.

I think this decision needs to be taken on a case by case basis, instead of a universal answer. You need to evaluate the lifecycle of the project. If this project is going to be around for only 1 year (like a game or marketing campaign that quickly ramps up and then dies down), you're better off getting it done in Objective C. The client will be happier given their familiarity with Objective C, and you'll have an easier time explaining it to their in-house team.

However, if this is longer term bet like an app that's going to be in use after 3-5 years, you should have a honest discussion with the client about considering Swift. While Objective C is more well understood and supported right now, that might not be the case in 3-5 years. Most Apple developers would rather be writing Swift code in that timeframe, and any ObjC code will be perceived as "legacy", difficult to debug, and abandoned code that no one likes to touch.

I've worked on many iOS projects like this, which contain pre-ARC code, which no one likes to go near. Bugs in that code tend to be ignored and entire features are left to rust because the source code is so dated that it's better to leave it alone than risk breaking anything by modifying it. If this project could end up in that state, it's better to be future-proof and start with Swift. However, if it's a short term app, choose the path of least resistance, which seems to be Objective C at the moment.

Since this discussion is about sales, I'd like to share a nifty little app for tracking sales that have already been made: http://www.bottomlinehq.com

Founder of Bottomline here. Happy to answer any questions about architecture, design or product. Love to hear any thoughts!

Apparently someone out there still uses Firefox.