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.
Ya, we love Firebase! Use Firebase functions heavily and i've been very pleased. That tied with redux works so smoothly. It's a different way of thinking about things but I find it so much easier to maintain and reason about than your conventional rest service.
Couple things I wish it had:
1. Ability to `keepalive` certain functions. Cold start is real. We have gotten around this via app engine cron that triggers certain functions.
2. Schedule them on cron. We have gotten around this using app engine.
> One thing I didn't see mentioned in this article is Firebase.
Can confirm, I'm also building my startup off of Firebase.
Super easy to get up and running with. I was talking to a friend at Amazon about how I create serverless HTTP entpoints and he was impressed that getting started with it was a 10 minute affair from "never done backend programming" to "REST endpoint setup." Another half an hour got me full end to end auth working from my app to my endpoints through to Firebase DB. FWIW I haven't investigated what it'd take to do the same within Amazon's eco-system, but from what I've gathered I'd have to understand a few more concepts than the simple "npm run deploy" that is the heart of Firebase's serverless offering.
Firebase's serverless stuff is dead simple. Wish the emulator was better though, I can'd do encrypted endpoints on localhost, which means 90% of my API can't be tested locally. Having to deploy to the actual service seriously adds to my code-deploy-debug loop!
> I can'd do encrypted endpoints on localhost, which means 90% of my API can't be tested locally. Having to deploy to the actual service seriously adds to my code-deploy-debug loop!
Try using ngrok (https://ngrok.com/). It can forward public HTTPS to localhost HTTP.
Have you migrated anything off of Firebase? Or still kept the “base” projects and upgraded around it? I’m interested specifically in how expensive Firebase is for popular products
I haven't migrated off of Firebase but this is something I've thought a lot about as I've selected Firebase for many of my client projects.
As far as I can tell there is no open-source alternative with feature parity that makes it easy to migrate away from Firebase. I'd be curious to hear about how people have done this.
This is actually what I'm afraid of - specifically vendor lock-in and being stuck with a stack that has high operating cost. From some of the comments I've seen, Firebase has high operating costs. But I'm still planning on testing this out myself with a small project soon.
If you like Firebase, I'd like to give a shout-out to Sanity [1]. (Disclosure: I work part-time on the backend, but I'm not an employee and I don't work on the product itself; but call this a shameless plug if you will!)
Sanity is a headless CMS, but the API itself is like a souped-up Firebase and can be used on its own without adopting the Sanity UI. It's got many of the same features -- web API, change watching via WebSockets -- but adds support for joins, fine-grained patches (CRDT-like but not actually), transaction history APIs, fine-grained document-level permissions, and many other neat things. We are particularly proud of the query language, GROQ [2], which is a very powerful superset of JSON that allows you to express transformation pipelines over structured data.
Sanity is hosted on Google Cloud, too, so performance when used inside GCP should be great.
Firebase is very much easy to get started for mobile apps. You have nice console to create project, and as developer you deal with just its SDK, one CLI and simple API. For something similar to Firebase in AWS, you need to make use of Lambda, API Gateway, DynamoDB, Cognito separate products, which has steep learning curve. And then you need to know the AIM security to get started. AWS has a Mobile Hub product which is trying to make things easy to create mobile apps by automate some of these AWS products for you. So now you have to learn awsmobile CLI tool on top of the core awscli tool. And if you develop for the web, they have this AWS Amplify Javascript library on top of basic JS SDK library which has a higher abstraction thus to make things simple (or worst). If you're new to AWS, you often struggle with which library should one learn and use. And if you use AWS Ampify and read the documents, it is as if the library is build for React. I'm not sure why AWS can be so married to one web stack. So much emphasis and priority is given to React and React Native in this library. They will give the excuse that React is what their customer wants. They now have mature React/React Native Amplify library thus giving the impression that to use AWS its better to use React/React Native. So they spend resource on AWS-Amplify, even move one of JS cognate-identity-js SDK under this umbrella, hoping the world will standardised on JavaScript and React Native for iOS, Android and web. So what happen if you're developing a mobile app using Unity, Xamarin and Flutter? No luck as they only have SDK for iOS, Android and web. Compare this with Firebase that has SDK for iOS, Android, web, Xamarin, Unity, Flutter and C++. AWS has an opportunity in AppSync to make a product as easy to get started as Firebase. What is required is native mobile SDK for iOS, Android, web, Flutter, Unity, Xamarin that is not just specific to AppSync and GraphQL, but also add in authentication, analytics etc APIs. Something like Firebase SDK API. AWS is still stronger for enterprise usage. And you can’t use Firebase in China due to its use of Google Play services. But Firebase is definitely a weapon used by Google to draw customers into other Google Clouds offering.
Firebase is great, but in my little experience, as it's database grows, it becomes clunky to sort and query, especially since everything is pretty much done client side.
Try Cloud Firestore, it has a lot of improvements with querying over the RTDB. I can also confirm sorting/querying is handled server-side. (Disclaimer: I'm the PM for it and use it for my own side-projects)
Firebase is great, but covered under a separate agreement with Google, and its terms aren't as friendly to corporate users. For example, they still aren't encrypting tenant data at REST. Nothing is COPPA compliant.
"Each Cloud Firestore object's data and metadata is encrypted under the 256-bit Advanced Encryption Standard, and each encryption key is itself encrypted with a regularly rotated set of master keys."
I know that this is required by various security certifications - but is there a reasonable threat model that it actually protects against?
The only one I see is someone physically stealing the hard disks out of the servers, which is impossible if you are using a trustworthy cloud datacenter instead of a server in your bedroom.
> The only one I see is someone physically stealing the hard disks out of the servers, which is impossible if you are using a trustworthy cloud datacenter instead of a server in your bedroom.
If you are using a public cloud data center for private data with regulations around authorized access, there is basically 100% chance that people without access authorization have physical access to the servers and their disks in a manner where there is no direct knowledge of the data owner of what occurs, which makes the threat of “unauthorized person gains physical access to the hard drive and steals data” greater, not less, than “a server in your bedroom” (or, more relevantly for corporate use cases, in a corporate data center for which you control physical security.)
I lot has changed in the last year or so, might be worth looking again. Most of the backend services are under GCP's terms of service, products like Cloud Firestore all do encryption at rest, etc.
Hi Magsafe,
Sadly not, and we don't have a mid-term plan to do it.
From my research, the only charting library that supports React Native at the moment is Victoryjs: https://formidable.com/open-source/victory/
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.
> 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.
More developers use Windows than any other platform. Your entire comment epitomises the cultish bubble that many HN developers seem to live in, completely oblivious to the rest of the world.
This makes me feel old because I've heard this same speech when it was about assembly language:
"A real programmer won't use a high-level language like C or Pascal. A great program is one in which the developer has written every machine code instruction to maximize performance and minimize memory use."
(Btw, Instagram has been natively on Windows Phone for at least a year.)
> "The developers who create those amazing apps on iOS are not going to fall for this. I'm one of those developers"
>"I will not accept my brand being introduced on Windows or any other platform using a glorified code generator"
Good, but there are some big companies that already are doing this and have no problem with apps running on subsystems to allow be in multiple platforms. King, Gameloft, EA and pretty much any dev using already Unity or Unreal is using a similar mechanism to be crossplatform.
This is just democratizing the mechanism so developers who didn't have access to those tools could port their apps more easily.
As a developer working at a smaller shop where software isn't a main focus this is great news. Not everyone is an artisanal software developer, sometimes you've just got to give you users your content and services where they are.
With a tin ear no less. It seems that these types of statements focus on a small world vision devoid of a taste for, or experience, within the walls of mid and larger corporate entities whose systems are windows 10x over. Knowing that a massive client like a retailer, financial institution, etc. could put heat on an app developer to bring it to Windows because of the bigger savings that way for the client is big. This isn't about Candy Crush. This is about integrating that app which some business unit loves into the larger IT structure of bigger orgs.
Consumer myopia misses the billions related to "boring" apps that corporations use. Today's keynotes definitely balanced target markets. This wasn't a consumer-only sampling.
Apple devs love money like everyone else, so you should consider the benefits of adding support for WP.
1 - There's a lot less completion in the windows store.
2 - You're bringing fire to cavemen, it doesn't need to be pixel perfect.
3 - The Windows 10 platform has some pretty amazing possibilities, you might want to dip your toe in the water without re-writing your app.
While I agree with your "perception" problem all that has to happen is one article in the WSJ written about an iOS dev who languished in obscurity in the App Store only to find riches in the Windows store. Then the gold rush will begin, just like Facebook apps, iOS apps, and lately Android apps the rush will be driven by outliers.
> I'm a full-time iOS developer and want to share my perspective on this news.
As someone who spent the better part of the last 3 years porting things, I'll share my rebuttal :)
> I will not accept my brand being introduced on Windows or any other platform using a glorified code generator.
That's a rather negative slant on a compatibility layer - one that must exist if you're doing multiplatform dev in a reasonable fashion (i.e. not rewriting the entire application for every platform.) Granted, one you write yourself will likely suit your app's needs better.
> 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.
I have never seen a perfect app in my life. Regardless, even if you want to take this route, having a compatibility layer you can lean on to get things up and running, before you begin to replace the things that aren't up to snuff, can be incredibly useful. I've repeatedly used this kind of technique to good effect - relying on banned APIs for Windows 8 ModernUI apps before replacing said calls with their WinRT equivalents, using slower POSIX I/O APIs on PS4 before replacing them with their faster platform specific equivalents, etc.
The nastiest bit of porting was always the big elephant in the room which I could not (efficiently) handle in this manner - the graphics APIs. Maybe 10-20 kloc of platform specific code, written blindly in the hopes that it would be roughly along the right lines, and that my program would one day link on the new platform.
If I was lucky, I'd be able to recognize bits and pieces of what I'd rendered on my first run. I was frequently not lucky - but a program that can run can be debugged, and so I did.
> 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.
That might work for small mobile apps. The projects I've worked on are simply too big to afford this kind of effort. We would much rather analyze every line of code that matters, and ship within a lifetime. Chances are, a compatibility layer will handle some things which I won't need to replace. One of the things that annoyed me greatly for my windows 8 port, was that so much had to be replaced simply because the older APIs were banned. Plenty of that code would have worked just fine to ship with, otherwise - it felt like busywork. E.g. instead of CopyFile or CopyFileEx, you'd be forced to use CopyFile2 - except the latter was unavailable on Windows 7 and earlier, so we had to keep around both versions for our platform abstraction layer. This got nastier with the OVERLAPPED I/O bits of code...
> Windows' code conversion isn't going to encourage the really good apps to migrate
Simply put, I disagree. Although we agree that it's no panacea - it's quite unlikely to be as simple as Copy, Paste, Build, Profit.
> If all it involved was learning a new language or porting some code, developers would do it
I personally know and regularly have lunch with counterexamples. Developers who insist that the only reason they're not targeting e.g. Android is that they don't want to bother porting some code. Ditto for Windows. They don't think porting some code would have an acceptable return on investment, so they don't bother with it. They already know the languages and APIs involved, too.
> just like they learned to go from Objective C to Swift
They didn't learn to do this. Neither have I - why write platform specific Objective C for my logic, unless I'm actually dealing with platform specific details? The vast majority of my code does not benefit from being platform specific, being instead written in C++, which means the vast majority of my code does not benefit from replacing Objective C with Swift.
Again: There simply isn't an acceptable return on investment. A few horror stories of Swift compiler bugs encountered by early adopters overheard in my local IRC channel helped remind me of the costs of following the latest shiny thing.
> 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.
At least this I can agree with :). The cross-platform developers I know won't shrug, however - and will note that one more barrier making Windows dev not worth it has been, if not eliminated, lowered.
> I will not accept my brand being introduced on Windows or any other platform using a glorified code generator...
Where did you get the idea that this is a glorified code generator?
> Developers avoid Windows for far more complex, intangible reasons...
Maybe mobile developers do, but outside of that there are whole industries that are centered around Windows. I see a lot of workers using Windows on little devices now too. Just yesterday a guy came to my house to inspect our lease return vehicle. When he was done, he whipped out this tiny little laptop with a touch screen that I had to sign with a stylus (which worked perfectly). It was running Windows 8 and that was probably the tenth time I've seen something similar in the past year.
> ...sadly they have not overcome the perception and mindset challenges of a dieing platform.
Bullshit. Windows is better than ever. More people use it than any other desktop OS. There are millions of IT departments around the world that would laugh and laugh and laugh if you suggested that they use OS X or Linux instead of Windows.
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 used to scarf down lunch as fast as possible and get back to work. Then I met my wife (who's South Korean). Koreans, despite being workaholics (in a grossly simplified general sense) have a cultural predisposition to drop everything and savor their meals. It drove me absolutely up-the-wall when we first met. Meals were something to get through as quickly as possible and then back to work.
But over time, as my work responsibilities have increased (and my work stress), I've learned to value meal time as a moment of peace in a stressful day -- an island of solitude. I take meals now with purpose, savoring every bite, spending the time to enjoy the food and simply enjoy the act of eating. I seek out places with nice atmospheres and good quality food.
As a result my health is better, my stress is better managed, and I find the pacing aspect of it keeps my head in the game when I return to work.
It's been an important lesson I've continued to enjoy.
I know other people who don't like this, maybe it's an introvert/extrovert thing. But the 30min-1hr lunch where I really just enjoy my own thoughts really gives me a second wind...especially late in the week.
My work environment has a high concentration of nerdy people with similar interests to mine, so I look forward to our lunchtime conversations, even though I'm also pretty strongly introverted.
I'm really really glad you mentioned this, it's something I wanted to touch on in the blog post but it was getting too side-tracked. I'm definitely in the same boat as you, my previous job used to be in an open office environment (at two different co-working places so it was LOTS of different teams worth of open office environments) and my lunch hour would be the only alone time I got.
Everything changed when I started at Stack though. As an introverted person I don't always want to be alone, but being alone is what makes me "recharge" so to speak. What's nice about having a private office all the time is I can choose to communicate with other people or not, there's always long-running Google Hangouts I can drop into if I just want to talk to another human being, or I can choose to be alone by myself for the entire day. Lunch though, is the only time I get face to face with my coworkers and it turns out I kind of miss that from being in an open office environment.
There's lots of people here that work on different teams and do drastically different things than me which would make it so I wouldn't communicate with them at all if I didn't simply grab lunch at the office and sit down at a random table.
I definitely agree with you that lunch as a team should never be mandatory though, it's asinine to steal an extra hour or whatever from everyone at your company with the goal of "morale" or whatever they want to say behind it. I'm super happy with the setup at Stack though, it works pretty well.
Are you really doing this? My personal record ( when I was a full time employee ) was 4 hours of summed coding time ( I track my time with RescueTime [1] ).
I was usually finding myself to code ( commit actual features and finding cause of bugs ) 2 hours before noon and 2 hours after lunch.
The other time I was usually in meetings / discussing issues / planning / writing documentation / improving dev environment / e-mail / communication with team.
It's definitely very optional here (at SE). Some people just grab a plate of food and go back to their office/desk/secluded corner to enjoy it by themselves or with a smaller group.
Working as a consultant, we always went out for lunch. After getting used to it (as a hard defined break from work), I can't imagine just staying at work all day without giving my mind a break.
If I don't leave work now, my productivity is shit in the afternoon. Well shittier than normal. As a morning person, I get 90% of my work done before lunch and tie up loose ends after lunch and plan the next days/weeks. Flex time is nice too, coming in to work at 5-6am then lunch at 11, home at 3 rocks.
No, you're not alone. For lunch I drive to the park, eat my sandwich while listening to NPR, then get out and go for a solitary walk in nature. It's a lot more refreshing than sitting and talking with the same co-workers I share the rest of the day with.
I've spent almost all of the preceding workweek partying and spending time with coworkers who are remote but currently in town. I feel like an empty shell of a human.
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.
