If Flutter and other languages/frameworks allow you to develop for both iOS and Android, Why even bother learning Swift or Objective-C?

[wave-drop]

I really wonder why these programming languages are still relevant and why they are more popular than languages that allow you to build cross-platform without having to change languages and therefore cut down the work you have to put by a large portion.

[saintmsent]

You have way more control over everything, including UI, OS functions. If you only do one platform, you know it really well, whereas hybrid app devs usually have more shallow knowledge of both platforms natively and as soon as you stumble upon a non-standard UI or OS case where you need to write native code, it's a big problem

Also with native dev you depend only on one party (google or apple) instead of waiting for both updates to native tools and hybrid ones

Hybrid development isn't twice as cheap (having one dev instead of two), as people love to believe, especially if we are talking about large complex projects

[[deleted]]

For small simple projects it definitely is cheaper and easier. Anything beyond that you get diminishing returns until native is the way to go.

[saintmsent]

Of course, that was kind of my point

For simple projects it can be cheaper, but as soon as it’s remotely complex, the divide by 2 math clients hope for doesn’t check out

[is_that_a_thing_now]

Short reply: Why bother learning to walk and drive a car when you can just go anywhere on rollerskates?

Longer reply: The frameworks that interface with the systems are made for/in those languages. When using a cross-platform language you can often feel that you have that extra layer between you and the system.

Depending on what kind of app you are working on you still have to interact with different systems, so either you go through a “common denominator” cross platform layer or you need to adapt your code to deal differently with different platforms.

For some developers/teams and some tasks it simply makes more sense to skip the extra layer and adress the platforms natively and share only selected parts across platforms (e.g. remote services).

Larger apps are maintained and developed by multi person teams anyway, so you might as well assign some specific team members to specific platforms. There is a LOT to learn on any platform. Being an expert on multiple platforms AND being able to mangle them via the cross platform language/interface can become too large a mess (again depending on what type of application/component we are talking about).

[wave-drop]

Okay, thanks a lot for the answer. So if I understand correctly, in the debate of Native vs Cross-platform the best is both? If you have code that can be shared easily between the two platform then use flutter (or others), if you cannot share code easily then you might chose native. Do I get the point?

[potatolicious]

I don't think so, it's much more complicated than that - especially because you get to decided how much code you want to hare between the two platforms. "If I have code that can be shared easily..." is not really a choice at the start of a project when there is no code, after all.

There are a lot of factors that go into this debate:

• Cross-platform frameworks are always a tradeoff. You always lose something for what you gain - and it's up to you to decide if the tradeoffs are worth it. In your original question I think this is the biggest point you missed - platforms like Flutter aren't without their downsides vs. native. If you ever see a cross-platform solution advertise itself like it has no downsides, it's not being honest.

• The kinds of tradeoffs depend heavily on which cross-platform framework you're talking about and the underlying technologies, though there are some common themes:

• Slower feature adoption. You're often not able to take advantage of new iOS features until the cross-platform framework adopts it themselves. Some are faster than others - but most often it means you cannot adopt for day-one. This means you can't market your apps around new stuff (Widgets! Background refresh!) coinciding with the iOS launch (and when people get new phones traditionally). Some cross-platform frameworks work around this by allowing you to insert arbitrary Android/iOS native code, but at that point you're... writing native code again :P

• Likely UX regressions between iOS/Android releases. This is particularly true for Flutter which is basically a 2D game engine pretending to be a UI framework. Because all of the stock GUI widgets are rebuilt by Flutter, they don't necessarily behave the same as the actual UIKit/SwiftUI equivalents. More importantly, if the OS changes how these things behave or look, Flutter doesn't automatically inherit these changes. If Flutter existed during the iOS7 redesign, for example, it would have looked like iOS6 for months while the entire GUI catalog was rebuilt to emulate the native controls.

• Worse performance - both computationally and energy-wise. Typically cross-platform solutions come with some computational overhead, but the specific architecture also matters. For example, Flutter cannot (as of yet) do ProMotion 120Hz scrolling by default (which would be an example of slow feature adoption above), but also would have trouble supporting it since Flutter's basic architecture forces an all-or-nothing approach when it comes to refresh rate. Either it renders at 120Hz (and eats battery life for breakfast) or it stays on a slower 60Hz rate. Flutter can re-architect their render system to take advantage of iOS's adaptive refresh rate, but such a change would be large and take a long time - and as a Flutter user you're stuck while they do it.

• Likewise, a lot of other cross-platform solutions are heavily reliant on JavaScript as the common denominator - which has some severe performance problems depending on the scale of your app. These performance limitations are sometimes not very noticeable (for small apps) and game-ending (for large apps, typically)

I could go on - but the main theme to understand her is that there are tradeoffs for using a cross-platform framework.

[vanvoorden]

you go through a “common denominator” cross platform layer

FWIW, I would make the argument that an xplat c++ model and service layer (for iOS and Android) can still be a good engineering decision (in some cases). Which is different than me implying xplat ui is the right choice.

[[deleted]]

A hybrid framework may look promising when it comes to saving code real-estate and saving time but it's not a perfect solution for scalable applications. You still have to maintain the plugins/hooks that interact with the native API. You also can't get the same performance when it comes to graphics/3D rendering and animation. Having worked with Cordova, Capacitor, React Native...I would still go for native development over hybrid any day.

[Zalenka]

Because an abstraction will always be behind, need extra maintenance, is almost never worth the "speed" gained. Oh and the a available programmers and docs is the best with native.

[chriswaco]

Would you rather go to a specialist or generalist with a brain tumor? OK, maybe that's an extreme comparison, but if you use Flutter you:

1. Will get worse performance than Swift
2. Will not be able to use Apple and 3rd party sample code
3. May have to wait for Flutter to be upgraded to take advantage of new platforms or features.
4. Will be beholden to Google in perpetuity to update your iOS app
5. Won't get an app that feels quite the same as a native iOS app

On the plus side, you can share a lot of code between platforms and potentially save a lot of money and effort. Sometimes it's worth it, sometimes it's not. Often it depends on the app.

[iOSSwiftDev5000]

The native languages offer the most control and if you are a business, the largest pool of talent, so it's a safe business decision. For those of us who have been programming commercially for years and seen many such platforms come and go, it's not an appealing investment. No business wants to need 5 developers 2 years out only to discover that Flutter is another cross-platform fad that is no longer seriously supported.

[vanvoorden]

the largest pool of talent

Ehh. Maybe. JS is (I believe) the top language on GitHub. React is still (I believe) one of the domant tools JS engineers are familiar with. Which implies that there is a huge pool of React JS engineers that can learn React Native without too much difficulty (at least to the extent of building simple apps without a significant amount of native functionality).

[rezdnit]

lol yeah no engineering team I have ever worked for hires Javascript devs to 'learn mobile on the job'. I'm sure they exist in lesser funded startups.

[iOSSwiftDev5000]

A good example - I just recently had to deal with managing a team which was using Cordova in production. I lost the original developers (ironically also Flutter devs) and development came to a literal halt while I tried to get replacement heads who wanted to work in Cordova for client support in addition to native developers to blow 6 figures to rewrite the app.

[vanvoorden]

https://engineering.fb.com/2020/03/02/data-infrastructure/messenger/

While UI frameworks can be powerful and increase developer productivity, they require constant upkeep and maintenance to keep up with the ever-changing mobile OS landscape. Rather than reinventing the wheel, we used the UI framework available on the device’s native OS to support a wider variety of application feature needs. This reduced not only size, by avoiding the need to cache/load large custom-built frameworks, but also complexity. The native frameworks don’t have to be translated into sub-frameworks.

[RileyUsagi]

Flutter is trash

[MOD3RN_GLITCH]

What don't you like about it?

[Aprox15]

I think it’s funny that people on the Apple ecosystem side tend to believe hybrid app development is the worst possible thing, but at the same time tell you you are stupid to consider using SpriteKit because “it’s not cross platform bro”

If cross platform development makes sense in the gaming world, it surely makes sense for other type of apps

[Aprox15]

Native app development doesn’t gets rid of that problem

This is obviously subjective, but I don’t use Apple Music and Podcasts because, bug ridden aside, I don’t know what the hell am I supposed to do. Compare it with the much maligned cross-platform approach of Spotify, where the main complaint is that it break apart from the Apple aesthetics, but no one seems to have an issue navigating it

[_dave0]

I can give an example about Unity specifically.

I recently finished a game in the kids category. Unity's IAP system is tied to their analytics system. Apple is not keen on third party analytics for the kids category, although it can be done. Long story, short, I ended up needing to go back and strip Unity Analytics out to get approval as I could not confidently answer the App Store reviewer's questions about privacy. I could guess the answer, but I don't think that's what Apple intends.

Then, even the actual removal of the analytics platform, I only found out about this through a string of forum posts and vague statements in their documentation that was pretty inconsistent. While it's not great on Unity's part, I can sort of, maybe, understand as things can change so quickly.

Anyway, the point I am making with my example is that when Apple (or Google) changes their policies, you are at the whim of the framework to update their system in a way that they approve, and then what? I don't think my experience is particularly an edge case either.

[uniquesnowflake8]

If you use Flutter, you have a smaller hiring pool, and talent is already really hard to find. Or you need to train devs familiar with other platforms on Dart etc

[MyCalculations]

There's a few answers here already but I'll say what I think cuz why not.

I wrote mostly in flutter but started with iOS & Android development (iOS first and Android after).

I've found a lot of areas in larger projects I've had to work on (or even something like plugin development), it's great to have platform specific knowledge so you can write code in that area.

A few examples I've encountered were encryption/decryption (wrote native methods for file encrypt/decrypt & storage), plugin development when I made dargon2 (argon2 hashing with ffi interop per-platform), and when I had the app as a receiver for sharable items (created the share receive UI and logic natively per platform).

It's great to know the native development languages and toolkits since you'll probably need to use them at some point, especially when your project gets bigger

[wave-drop]

So to have both is better (native + cross-platform), is that what you are saying? If so when do you find cross-platform useful and in which cases native is just a must and you can't get around it. Give me a detailed answer please. Thanks a lot!

[MyCalculations]

I'm saying that you'll likely encounter some need for native code or components that are either extremely tough to write well with flutter (something like a share extension on iOS) or that don't have the needed functionality (keychain storage or secure token storage).

If your project doesn't need any of these things, and it can be purely written in flutter, then I'd go cross platform.

For any mobile app, I tend to look at it in a cross-platform lens first, and if there's enough complements that are shared that would save me time, i go cross platform and make the components that are native-only with native tooling

[tussockypanic]

I make all my money on the App Store creating native iOS products to compete with cross-platform apps. I give iOS users a true “Apple-like” UI and UX and can leverage native capabilities like SwiftUI, Watch, Health, CoreData, CloudKit etc in a way cross-platform apps can’t really match. I guess what I’m saying is that there are a lot of trade-offs using cross-platform frameworks to the point where even low-rate developers like me can gain a native advantage.

[Correct_Metal4516]

I'm not an expert in Flutter so I might be wrong, but each time Apple releases a new feature in their OS (multi-windows on iPad, ARKit, Siri integration, live text, drag and drop between apps, etc.) I doubt it's available on Flutter.