5 ms·
Maybe harkening back to the old-school days of HN, but I'd be keen to hear about the tech stack you decided to use in building the app, what your considerations
by pedalpete 5y ago
Maybe harkening back to the old-school days of HN, but I'd be keen to hear about the tech stack you decided to use in building the app, what your considerations are for multi-platform, and advice for start-ups getting ready to launch their own apps.
- cjbest 5y agoWe'll get you a real answer about how the tech stack is today. But for now I can tell a war story that might be fun. I'm one of the founders, and am in a very much non-technical role now as CEO, I did write a bunch of the very early code (some of which people curse my name for to this day.) When we were starting, I was limited by how many new languages/frameworks I could learn at once. I started writing the backend in python, because I knew it a bit. But our first writer often needed to use Chinese characters, and in python 2.X I could never get unicode strings to work properly. I couldn't upgrade to python 3, because on google cloud I would have had to learn Docker and I was already learning too many things at once. Eventually I got so frustrated I threw out several days work and started the whole backend over, with node + Postgres hosted in Heroku. This ended up defining much of the stack we use to this day, which might be good or bad depending who you ask. At least unicode works though :)
- onefuncman 5y agoA few (but not too many) years ago I inherited a custom compilation of python2.x to make unicode strings work properly. You made the right call, lol.
- pedalpete 5y agoI have memories of the Python compatibility issues causing huge headaches. We're back to using Python due to ML requirements now, but it kept me away for years.
- pjscott 5y agoI’m curious: what was the issue? I’ve used python 2.7 with Unicode pretty extensively, in a wide range of languages, and have never had problems that weren’t my own fault.
- sachinmonga 5y agoI tagged in one of our lead engineers to talk about the tech stack, but can chime in re: considerations for multi-platform. We are sprinting as fast as we can to get an Android app out the door. We're also planning on investing more in the reader experience on web. Some time ago, we launched a web reader (reader.substack.com) in beta and have some exciting ideas in the works to evolve that surface. Beyond Android, when it smaller platforms like iPad / Desktop apps, it's mostly a matter of looking at the data and listening to users. With a small team, we have to be judicious with prioritization, and as we increase the surface area for readers it's important that the experience for writers remains clear (right now their readers can already read on email, web, and mobile).
- demosthenes714 5y agoJohn here, one of the app engineers at Substack. Our team has lots of experience with Swift and values the level of polish you can achieve natively, so went with that. We try to avoid third-party dependencies so native implementation and customization of UIKit, URLSession, and CoreData are important to us. Cross platform frameworks like React Native, Flutter, Xamarin, etc are super interesting but in our experience can hold an app back long term. As you're able to dedicate more resources to the product, it's more likely that you'll want custom UI (animations, transitions, etc) and functionality that require full access to native APIs. It's a tough decision to make for early stage start-ups but we also went with native at Cocoon (our last startup which was acquired by Substack). I think some important factors that should go into the decision are 1) how important you think both Android and iOS support are out of the gate 2) how soon you'd expect to be able to hire native engineers for both platforms 3) your long term vision for the product and its desired complexity. We love Android (I've got some Kotlin experience myself) and will have it out ASAP, but with the existing email/web product there is less pressure for cross platform in our case.
- gonehome 5y agoThanks for building a native app!
- pedalpete 5y agoYeah, we've started looking at Kotlin Multi-platform Mobile to keep our business logic cross-platform, but then native UI. The discussion we're having is if it is mature enough for our needs now, or if we write in Flutter with the expectation we throw it all way in the near future. We all use Android while our users are mostly in single platform approach won't work for us. We're also a hardware company, so need BLE and WebBle support isn't good enough for us. Thanks for your answer
- shroompasta 5y agoI'm curious as I think I'll be making this decision in the near future. > it's more likely that you'll want custom UI (animations, transitions, etc) and functionality that require full access to native APIs. Besides the custom UI stuff, as I think React Native has some decent animation support nowadays, what specific native APIs were needed in Substack's case that made React Native an ineligible choice? As text being the main content for Substack, Its hard for me to imagine why React Native wouldn't be sufficient for a relatively simple app. Discord, undoubtedly, has more complex UI needs compared to Substack, however it's humming along just fine with React Native. What makes React Native capable for Discord, but incapable for your needs?