6 ms·

John 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 wit

John 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 ago
Thanks for building a native app!
pedalpete 5y ago
Yeah, 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 ago
I'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?
- saagarjha 5y ago
  Note that Discord's main conversation view is native UITableView for performance.
  - shroompasta 5y ago
    this article suggests otherwise. https://discord.com/blog/how-discord-achieves-native-ios-performance-with-react-native https://discord.com/blog/how-discord-achieves-native-ios-per... > At first, we felt that maybe doing it purely in JavaScript was futile. We spent some time trying to glue together UITableView with React Native, and while we made meaningful progress, it started feeling overly complicated. After stepping back and thinking about what else we could do — it hit us. We already solved this problem once before on the web! We already had an internal List component that virtualizes its children. There is no way we could just drop it into React Native right? I'm also curious why it took them so many pain points to reach list virtualization as their solution. That would've been my first thought.
    - saagarjha 5y ago
      > We’ve actually implemented our core chat view natively because lists don’t perform well for many dynamic rows.
      - shroompasta 5y ago
        That was their initial problem. Upon further reading, you will find that they found a solution in dealing with Lists with React Native. My initial comment had the answer - they brought in a component that visualizes lists from their web platform, and it worked seamlessly in React Native. So no, while they initially implemented their core chat view natively, they are using full blown react native as of right now.
        saagarjha 5y ago
        No, they aren’t. I would know, as I have a debugger attached to the process right now.

gonehome 5y ago

Thanks for building a native app!

pedalpete 5y ago

Yeah, 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 ago

I'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?

saagarjha 5y ago
Note that Discord's main conversation view is native UITableView for performance.
- shroompasta 5y ago
  this article suggests otherwise. https://discord.com/blog/how-discord-achieves-native-ios-performance-with-react-native https://discord.com/blog/how-discord-achieves-native-ios-per... > At first, we felt that maybe doing it purely in JavaScript was futile. We spent some time trying to glue together UITableView with React Native, and while we made meaningful progress, it started feeling overly complicated. After stepping back and thinking about what else we could do — it hit us. We already solved this problem once before on the web! We already had an internal List component that virtualizes its children. There is no way we could just drop it into React Native right? I'm also curious why it took them so many pain points to reach list virtualization as their solution. That would've been my first thought.
  - saagarjha 5y ago
    > We’ve actually implemented our core chat view natively because lists don’t perform well for many dynamic rows.
    - shroompasta 5y ago
      That was their initial problem. Upon further reading, you will find that they found a solution in dealing with Lists with React Native. My initial comment had the answer - they brought in a component that visualizes lists from their web platform, and it worked seamlessly in React Native. So no, while they initially implemented their core chat view natively, they are using full blown react native as of right now.
      - saagarjha 5y ago
        No, they aren’t. I would know, as I have a debugger attached to the process right now.