Expert Talk: Native vs Cross-Platform

Lately, mobile developers have had to answer this question the most: Shall we go native or use a cross-platform framework? And if so, which one?
Sebastiano Poggi, team lead at Jetbrains, and Carl-Gustaf Harroch, founder/managing director at Novoda, explore current best practices around modern mobile development highlighting the impact of team collaboration and matching technologies across platforms.

Native vs cross-platform

Carl Harroch: Okay. So, hello, I'm Carl Harroch. I'm the managing director of a digital product agency called Novoda. And I'm here with Sebastiano Poggi.

Sebastiano Poggi: Hi Carl. I am a team lead on package search at JetBrains. It's one of the many things you can find in IntelliJ, which is your favorite, I think.

Carl Harroch: Yes. Welcome to "Unscripted." So I think the topic of today, and we're gonna go with your talk that you got on Monday, which is around native versus cross-platform.

Sebastiano Poggi: Yes.

Carl Harroch: So tell me, Sebastiano, should I go native or should I go cross-platform?

Sebastiano Poggi: It depends, that's the keyword. Like, jokes aside, I think there are a lot of factors to take into consideration when making that choice. There are also a lot of wrong reasons to make that choice. Not just saying there are wrong reasons to choose one or the other. There's even...like getting to the point of asking yourself, should I do one or the other, if you already have a product, then there might be reasons where you're asking yourself that because you feel like you're in a bad position and you need to dig yourself out of a hole maybe. And you're like, "Okay, maybe the next cross-platform framework is gonna solve all our problems." Generally, technology cannot fix that kind of problem.

But if that's not your situation, if you're in the case where you have a solid org and a good product that you want to develop a mobile app for, then the choice between native and cross-platform might depend on several factors that are, for example, your own company's needs. So your product needs are the first thing. If you need to use some things that are very much tied to the platform you're on, then probably doing cross-platform, for example, doesn't make that much sense because you will end up spending a lot of time talking directly with the underlying operating system and you need to do it per platform.

Recommended talk: Kotlin Flows and Channels for Android • Ryan Pierce • GOTO 2020

So you still need people that do Android and you still need people that do iOS. You kind of need it in general, but the more you have to talk with native stuff the more native people you need, and you cannot get away with having a team that can juggle both platforms at the same time. You might find someone that can do both Android and iOS at a high level, but that's fairly rare.

Another thing that might guide your choice is the fact that maybe you already have certain capabilities in your company. I know that's a word you like a lot. If your company already has a native team and you're thinking maybe I wanna switch, for example, to Flutter or React Native or Xamarin, or any of the web-based frameworks, or Kotlin Native, whatever you want, it doesn't matter. The point is if you already have a team and you go to them without telling them, without talking to them, you are probably going to find out that the people you already have will not want to do work with the cross-platform framework. That might be problematic because it might lead to a lot of people in the team leaving and then you being on a deadline stranded in a time where you are making a very big investment to maybe rewrite your application. That also is probably something you should try to avoid.

How organizational dysfunction impacts app platform choices

Carl Harroch: Yes. I mean, you touched on organization structure. How your organization behaves, and also on the bad choice of going with, let's say, cross-platform, even asking yourself the question if the organization is not set up to pose that question. Do you have any example of an organization where there's dysfunction in that area in which they come to like, "Okay, I'm not working out why this is not working?" And then they say, "Let's figure out if cross-platform is a solution." Can you maybe elaborate on some of those dysfunctions?

Sebastiano Poggi: So, the are different factors that can lead to mobile a product failing. One of them can be, I would say, organizationally speaking, a management problem in the sense that you might have the entirety of your company's technology stack that lives obviously under a CTO and it's considered tech, but for some reason, your company might be considering mobile as part of the product. For as good as product people can be, and probably are, they are not tech people, and they don't necessarily understand what is needed for a mobile product, or generally speaking, a tech product to thrive. On top of that, it can also compound with the fact that there can be tribalism between the people that are working on the tech side of things and the people that are working on the mobile/product side of things because then they're not aligned. They don't have necessarily the same priorities.

For example, the CPO and the CTO come to talk to each other like, oh, the CPO says, "I need to do an app. I need an app because the product needs an app." And the CTO is like, "Well, fine. We're gonna have the back-end people do something for your mobile team." But then the incentives are not necessarily aligned. The back-end team that creates the APIs that the mobile application will end up using, might not care. They might have other priorities. They might use a technology stack, or even just a way of doing things, that doesn't work well with the mobile applications, because, historically speaking, back-end development has been, and it still is probably, closer to the web than it is mobile. And web compared to mobile is a relatively straightforward thing in the sense that mobile can include a variety of things that is not just the phone you have in your pocket, but there are tablets, there are TVs, there are wearables, there's cars or phones on the table.

Carl Harroch: I'm just gonna put it.

Recommended talk: What’s New in Swift • Daniel H Steinberg • GOTO 2019

Sebastiano Poggi: So when it comes to the needs of the mobile team, they might be different, even just between different form factors, because the ways people use a smartwatch are different from the ways people use a TV and they're different from the ways people use a car. Like, one thing that happens often is that maybe back-end people don't think in terms of offline, which is very important for mobile, because mobile...well, you go in the tube and you don't have coverage, so what do you do?

There's a lot of work that happens on the mobile side to compensate for that. But you might also, as a mobile team, have to work around the fact that the server assumes, in one way or another, that you're always connected, because the web is, by definition, almost always online. And sure, you can have offline behaviors that are possible on the web as well, but they are fairly marginal and there are not that many cases in which that is relevant because you either have a connection and connect to the internet and surf the web or you don't, so.

Does full-stack include mobile?

Carl Harroch: I've seen that quite frequently. The way that I like to think about it, especially when a browser experience is a very active experience because you open the browser and you have the intention of doing something like checking a bank account or something like that. So, it's a kind of active real-time experience, including for the back-end, because it gets the request and then serves it back to the web. While on mobile, you can look at it more passive and event, because it can be location-based, it can be a certain time of the day. If somebody sends you money, then you send an event and you receive it.

So, the API or the way to describe the API or to construct the API tends to be fairly different if you start from the web or if you start from mobile. On your point where you say back-end is more aligned to the web, I think there's also a technology component there because when you say full stack you tend to have cloud abilities, Infra and so forth, and then JavaScript, and then potentially JavaScript web reacted similarly. And so the full stack is kind of like not including mobile. And then what do you...

Sebastiano Poggi: I mean, mobile is a front-end, but it's not a front-end for the back-end. It's a front-end that happens because in 2022 there are cases in which you don't need a mobile app, but everyone and their dog has a mobile app these days. So it is kind of like...it exists. It's a thing you need to consider. When I was mentioning that the back-end might not think in terms of the needs of a mobile app. Something that a mobile app does that websites never do is being proactive. So, a mobile app, and I think you will remember a project that you worked on where this newspaper wanted to get everyone the latest news when they were released. And the back-end was like, "Well, here is the whole thing."

But then the company couldn't just deliver that to the mobile device because it wasn't prepared in a way that made sense for the device. So what ended up happening was that there needed to be a middleware back-end that got the bunch of things, retranslated them in a mobile-friendly way, and then staggered pushing that notification of the new stuff is ready to all the devices, but trying to avoid congestions, because then again, obviously, if you send a push notification to everyone at the same time, your back-end is gonna go down because you have, assuming you have a popular service. But in that case, it was. So that sort of thing is the stuff that if you don't know mobile if you don't think about mobile as having its own needs, it's very hard to consider and is very easy to miss. And then you find yourself in a situation where like, "Ops."

Carl Harroch: Yes, I remember that project where we started first building, so there was something like 150 API calls to get like one edition. We started doing that first on mobile to be allowed this kind of like component where it was like, "This is ridiculous. It should be pushed somewhere else." Then we created this proxy. So anyway, the back-end was invented, then it kind of like was rest-based and not evented. Then we kind of made it even again. So we had this kind of layer to make it more mobile-friendly. So, in this picture, how can you alleviate that? What have you seen, like, from an organizational structure perspective in which mobile is accounted for either beforehand or at the same time or during the description of the APIs? Or is there technology that you've seen that works better than others in achieving that?

Sebastiano Poggi: In terms of technology, it's hard to say because, like everything, and I go back to my favorite answer, it depends on what the company's doing. And some teams have had a lot of luck using GraphQL. That worked very well for them because it allows them to be more flexible on the client-side and just also reduce the amount of traffic that the application needs to do to get the data that it needs. But at the same time, that might just move the complexity to the back-end side which might not be ready to tackle that and work on it effectively.

So that's one way. But also, you can probably do just fine with a rest API as long as what you're doing...like if you have...I'm thinking about a store. You have an app that allows you to buy things. You can probably be fine with REST APIs for most of the stuff you do, but maybe other scenarios would work better with a GraphQL API. I don't think it's necessarily technical. I don't think the tech you choose...I don't think even by itself will make something work. It might make your life easier. It might make your life harder. I've worked plenty of times on applications that were talking to back-ends that were almost hostile to the way mobile works, but then the app still at the end of the day worked. It was just a lot more work to do on the mobile side to compensate for the fact that the back-end was doing things in its way.

I'm sure they had reasons for them that made sense, but obviously, it made the life of the mobile team harder. What I think is very important is to design these things together and to account for the fact that when you want to do mobile, mobile will probably have different needs than the web. Then you will need to involve someone from the mobile team from the start from the moment you decide you're gonna do a mobile app, regardless of native, regardless of cross-platform, or anything else. You need to put everyone together and design everything and decide what they want to do. But also there needs to be buy-in from everyone. It cannot be like, "Oh, we want to do this so you have to help us." They're like, "But we already have a backlog full of stuff to do." Because you're gonna have stuff that is half baked or just you get whatever is there because that's what we can do and we can barely support mobile.

Carl Harroch: No, I was just going to say that I've seen, I think, through the 10, 15 years of us working with different clients, we've seen a lot of that where there are things, so a flow, and I'm not sure if this is that common today. Back in the day. it was, okay, you have people sitting in the room, including sometimes mobile, discussing, the next big release for the next 6 months or 12 months. They say, "Okay, we're gonna do this new search API or something like this." Then they go off and create the search API. They come back six months later and say, "Ta-da." And then the mobile team is like, "Well, we haven't really...I know we were part of the conversation, but it was six months ago. We need this like this now." And you put it back in the backlog and then it's another six months before you receive it. So you have this kind of like alternates of putting things on each other's backlog, which gives us a certain amount of time before release, which is way too slow in the pace of the current market. So have you seen another setup that works better?

Sebastiano Poggi: I've seen companies succeed with vertical teams where there is no one back-end team but there is a slice, a vertical slice that goes from the back-end to all the front ends that including web and mobile. Then, they work in a very close relationship in a very tight loop so that there isn't the risk that you just outlined of saying, "Oh, actually, the spec we discussed six months ago doesn't work." We just realized after implementing some other things that that doesn't work for us. Like everything, if you commit to something medium or long-term, you must keep up with the rest of the parties, so this it's not just, "Oh, yeah, we're done. Close everything in a sealed envelope and then come back with...oh, this is what you ordered. There you go."

That's something that happens unfortunately very often when different teams are disconnected again. Even in the case where they are under the same responsibility chain, they might just have, like, cold relationships, let's put it that way. And there might be several reasons for that. And I've seen several ways in which this can happen. Sometimes it's ego. Sometimes it's a lack of understanding, lack of empathy even between the different teams where you have...this tends to happen, especially when there is a strict deadline that the teams have to meet and they're not aligned.

So if one team starts to say, "Oh, yeah, but they're always demanding, but why can't they just use whatever we gave them already?" And the other way around, "This mobile team is like...or this back-end team, they don't want to do anything for us. They just care about their stuff." Then this builds up over time to the point where it's just like us versus them. It's very tribal, again, which can cause all sorts of problems. I don't have a silver bullet or recipe for success for that, except keep an eye on and make sure people talk.

Matching technologies across mobile and web

Carl Harroch: To this point actually on the tribals, like, okay, you know, back-end, front-end, have you seen or do you believe that maybe that's why some, engineer, head of the engineer will think like, "Well, look, you know, like back-end is writing in JavaScript. Like, maybe if we say React Native with this JavaScript in the front-end." Or, "You know, .NET in the back-end so, like, we can put Xamarin in the front end." And so they won't fight each other because they speak the same language. Do you think there's some of that thinking going on?

Sebastiano Poggi: I surely see, especially this happening after a previous iteration of mobile failed. They were like, "Oh yeah, you know, we had that. We tried that. It didn't work. But look at the backend. They're always on time. They're always shipping. They use JavaScript. Maybe this JavaScript thing works for mobile as well. Let's use React Native." And then you go to your mobile team and you tell them, "Oh, you know, from tomorrow, you start doing React Native." And then they all quit because mobile devs hate JavaScript.

Recommended talk: Xamarin Forms: Native iOS, Android & WP Apps from one C# Codebase • Mike James • GOTO 2015

Carl Harroch: I mean, I'm sure we've all hated JavaScript.

Sebastiano Poggi: No, no, no it's a generalization. But in terms of preferences, I'm sure people that have been hired to do native dev, probably prefer to do native dev. And these days, it's not hard to find a different job if you are tired of what you're doing. So, just saying, just think about that. Involve the people, talk to them and they might be on board with that, but you need to talk to them. If you impose things on people, they're not gonna like it most likely. So, talking to them. 

Aso, consider the fact that if you have native teams and you go to them and be like, "From next month, we do cross-platform." Half of them are gonna be... Well, all of them are gonna be like, well, "You only need half of us then? And then what happens next month? And am I even bored..." It's like, "Should I look for a new job?" And then you risk, again, finding yourself without a team to work on that, which...

Carl Harroch: Yeah. Okay. So this challenge is there between, let's say, back-end and front-end, like back-end and front-end of mobile. We should go and move to those cross-function teams and just remove the idea of back-end and front-end and just have one big family doing these things together.

Sebastiano Poggi: But that doesn't work for everyone.

Carl Harroch: It doesn't work for everyone. Even when you think it's gonna work, it doesn't work either. What I've seen is intention being good, especially in kind of the scale of sometimes like try to behave in a certain way. So microservices create the structure with all the capabilities in those cross-functional teams. And it usually starts with a good spirit. But over time, you then have the storefront team or like the profile team. And then suddenly, you start having...and then the mobile team, which are also weird. Because you have one which is product-directed or kind of like business intention that is described in the teams, and then mobile, which is kind of a platform as on the side, a bit like black crumps from everyone.

Team collaboration across platforms

Carl Harroch: We know where to put them. And if you have one engineer on each is a bit strange. But that's better than what you described, which is like fighting. But let's maybe take it down a notch toward... If we remove the back-end and just focus on the front-end between, let's say, iOS and Android, putting aside web for now, even between that two platforms, there seems to be a bit of... Are there enough differences to validate native development? Like, the experience or both from a developer experience also from the consumer experience is quite similar. So why are the team...or have you seen...I don't want to lead the question, but, like, have you seen teams working together between the two platforms, or what's your experience there?

Sebastiano Poggi: I have seen teams working together in harmony between Android and iOS. Sometimes that was because common enemy, the back-end, but it's not a healthy way to do that. But I've also seen teams working together in sort of a friendly competition where, you know, one of the teams gets ahead on the backlog, and then the other team is like, "Oh, it's not possible. They cannot do better than we do." Then they catch up and then they pass them. So you can, and at the end of the day, you should be able to work constructively between the Android and iOS teams. I think that's especially important to have these people work together, like, force them to have reasons to work together on stuff that goes from defining the tickets and planning the issues together.

I mean, some things are inevitably gonna be easier on Android and some things are gonna be easier on iOS, so they might not always be aligned, but in a longer cycle than a sprint, you probably want to make sure that they're focused on the same things and have the same goals. This can be complicated when you consider products that tend to bring in revenue, and then their performance is gauged on the revenue that each platform brings in, because, depending on the business model, the iOS team, can't do half of the work that and Android team does and bring in three times as much revenue because iOS users tend to be bigger spenders.

So, if you have a subscription model, for example, then it might be easier for iOS to acquire and retain paid users than it is on Android. So, when you decide on the success metrics for the different platforms, you need to understand that the audience might be different. It's always the case. Everything, as always...it's a generalization. And there are probably examples of cases where it's the other way around. But if your only metric is how much revenue a team is bringing in, the Android team is most likely going to always be behind, unless you have a very wide base of users, and then what you are monetizing. This is something we tend to see a lot in the mobile market where a company that maybe has a subscription model on iOS tends to do more the freemium thing on Android because that's how the audience that they're targeting on Android works.

Recommended talk: Building Resilient Frontend Architecture • Monica Lent • GOTO 2019

Carl Harroch: So understand your target audience a bit better?

Sebastiano Poggi: Yes. Understand the target audience. But going back to the original question about making the mobile teams work together, that's possible, and I've worked with brilliant iOS people in the past in my previous life as an Android developer. I think it comes down to the point where, as an engineer on either platform, you go past being a fanboy of the platform and understand that everyone is doing their best with what they have. And yes, there is no best. Like, it's something that when you're... I'm gonna sound very old. When you're young...

Carl Harroch: You're younger than me.

Sebastiano Poggi: Yes, I know.

Carl Harroch: Still still.

Sebastiano Poggi: When you start your career, especially mobile, there's a lot of people that are like, "Oh, you know, Android is the best," or, "iOS is the best." And you get to a point where you realize that that's not true. Like, different people will like different things, and iOS will work better for people that are probably not you, but their point of view is just as good as yours. Not like making it so that nobody's narky at the others for being in a different camp, let's say, is very important.

Measuring cross-platform success

Carl Harroch: I remember someone at Novoda who's been with us, probably one of the older people. They'd say, "Listen to the old man." Every time you wanted to make a point similar kind of like, "You can go and discuss your complexity and like the latest tech. Sometimes simplicity or proven ways of doing something are better. But from a curiosity perspective… you mentioned you shouldn't measure revenue as that product-driven. Do you have like a way to measure that harmony? I mean if you want to... If you are, I don't know, like a head of mobile or CTO looking at your mobile team and you want..."You know what? We want to have better collaboration." What should you measure? Or how would you go about doing that?

Sebastiano Poggi: I heard Mario Kart tournaments are really good for that.

Carl Harroch: It brings in the competition.

Sebastiano Poggi: Yes. But it's a friendly competition, you know? Jokes aside, well, no joke. That's true. It's like making things that people enjoy doing together helps. But fostering collaboration between the two teams... I think over time...when I was in Novoda, we tried things like on some projects having Android people doing code reviews of iOS stuff, especially once Kotlin and Swift were adopted in both teams so the languages are close and we can understand each other better. That's something. But I forget the rest of the list.

Recommended talk: Programming Kotlin: Why, How & Its Future • Venkat Subramaniam & Hadi Hariri • GOTO 2021

Carl Harroch: I remember that. They were like Kotlin and Swift, let's say, is like 80%, the same of syntax. So I find it fascinating when you hit code bases that are written in Swift and Kotlin, and even the models have different naming.  And you're just like, "What? That does not make sense in terms of..." The conversation had not happened. So, they've done it differently on different projects.

Sebastiano Poggi: But I remember at least one of the projects where we were doing the cross review, one of the things that we were explicitly looking for was this kind of discrepancies where... I mean, trying to be aligned in the things that the two teams are doing, allow people that are doing the code reviews across platforms to say, "Oh, we already done that and we code that that way". So maybe the structure of the code might be different, but the name...unless you're using a completely different pattern in different operating systems, which might make sense, but the name of the data models is the obvious thing where you need a shared language between the teams.

Also, that helps when it comes to talking with the back-end. If you can have a shared language with them as well, that also helps. But also product management and project management, especially when you write issues and stories and you're brainstorming the personas and the scenarios that you want to cover, having a shared language is very important. One is the serialized version and the other one is the one we get from the wire."

That sort of thing is important to care for, like explicitly consider once you start working on things, if the other platform has already done that, to make sure that you're on the same page. And maybe it doesn't mean that the first platform that gets there is the right one. It means that, once the other platform catches up, if they're not aligned, then it's a good time to have a discussion and consider whether either solution is better or if they're equivalent, which is also absolutely fine.

What is cross-platform development?

Carl Harroch: It's interesting. Like, you mentioned, as part of your description there, you said cross-platform. I feel like cross-platform thinking where you mentioned the merging or, like, when they kind of look at each other. So you feel that this type of development is cross-platform development because you look at...you know, you're going across the different platforms as a developer?

Sebastiano Poggi: I mean, cross-platform is a term that means many things depending on how you look at it. When we're talking about cross-platform frameworks specifically in terms of tech, we're looking at a single team that can target both platforms, Android and iOS. Especially distinctive I think is the fact that they can target both platforms using a single language and mostly the same build tools. There are exceptions, of course, because at the end of the day, you need to deliver an APK on Android and an IPA on iPhone. So the last mile, let's say, of the building process is still handled by the native tools, but the majority of the chain above will generally be handled by the same build chain for both platforms and just diverge at the last minute when it comes to packaging the final application. So that's one way of seeing cross-platform.

But then again, when you're talking about mobile, it's very rare that you want to target iOS or Android. There are niche things for which it only makes sense to target iPhone or Android. Some product categories historically have only targeted or mostly targeted iOS, so creative software and things like that where, historically speaking, Android has been behind, both in terms of the ability to handle media, but also I'm thinking about music creation, for example. Historically speaking, Android, until a few years back, had a serious latency problem that made it essentially impossible to create virtual instruments because of the lag between your touch on the screen, or your input, and the moment that the input was processed and the output came out was way too long and it was not a problem on iOS. So those sorts of things can mean that, sure, your product doesn't need, or cannot have, an Android or an iOS app. But generally speaking, if you do mobile, you probably want to target the widest audience possible and that means both Android and iOS.

Carl Harroch: And so, you describe a very specialized software like music production and similar like instruments, which I think you would probably go down the route of doing it natively.

Sebastiano Poggi: Probably.

Carl Harroch: Going complete at the side, have you seen an example, let's say, in which, like, the use of cross-platform was like a roaring success, not just saying, "Okay, well, it was good," but like this was transformational to the business?

Sebastiano Poggi: I have seen products succeed with cross-platform in the sense that you don't have to think that cross-platform is...like, doing cross-platform is not necessarily a hindrance to your success. And there are cases where doing a cross-platform app is perfectly fine because you don't need anything more than what the cross-platform framework gives you out of the box. The problem with cross-platform frameworks can arise when you need to get out of the... I'm not gonna call it walled-garden, because it's not.

But outside of the comfort zone of the stack you use say. Say, for example, you use Flutter and all your code is written in Dart. Like, you probably had to create a team to write Flutter because it's rare that a company already has Dart teams before starting to do Flutter, but you do. You do the investment, but then you need to interact with, say, a third-party library, a classic example of an analytics library that you must use because your business depends on it, but they don't ship you Flutter library. They only ship you the native version.

So you need to write the wrapper around the native stuff in native, so in Kotlin and/or in Swift, respectively Android and iOS, and then write the code that bridges the native wrapper you've done with the Dart code that uses it using the channels that Flutter provides you. And that's where the more of those things you have, the less benefit you get from using a cross-platform framework. If you don't need those, or if you need those but there is already a cross-platform library for that, then you can have a good product coming out. One thing I can think of, for example, I think last year, Philips Hue rewrote their app. There used to be two native apps. They rewrote it entirely in Flutter and they've invested a lot in creating a Flutter library that handles Bluetooth Low Energy so that they can talk to their devices directly from Flutter.

So, obviously, in their case, they had to write the native bindings for Bluetooth on Android and iOS, but then everyone else now can use Bluetooth Low Energy fairly easily on Flutter because of the investment that Phillips Hue has put into that already, and then they published it as open source.

Recommended talk: Flutter: The Best Way to Build for Mobile? • Kasper Lund • GOTO 2017

Carl Harroch: That's a good point. So like the kind of, like, the community around those cross-platform tools are important. Is there one in particular that you're excited about? Is there one that you feel is kind of taking over from the other one?

Sebastiano Poggi: I was looking for the talk that I gave the other day at numbers, and the trends I find are very interesting. So I looked at data on statista.com where they were asking mobile developers which cross-platform frameworks have you used for the past three years. And you can see that all of the cross-platform frameworks are going down in usage, particularly the web ones. They're going down very quickly, like Cordova. It used to be called PhoneGap.

Carl Harroch: It was...

Sebastiano Poggi: Yes. That's like the first generation of cross-platform frameworks, which was essentially, "Put a web view in your application, and now you have an app." It's like, "Not really." But the only cross-platform framework that has seen growing usage is Flutter. Even React Native is losing a bit of mind share and maybe market share as well. It seems to me, my perception, that the Flutter community is the community that is closest to native development. And in fact, a lot of people that do Flutter tend to come from Android background, maybe because it's, you know, Google here, Google there, just kind of like a natural path.

But obviously, some people know how to do iOS there as well, maybe as a second language or second platform. I don't see it as much in other frameworks. When you talk about React Native, that tends to be people that use react on the web that is like, "Oh, could also." And then the community around React Native tends to be a bit more web-centric than mobile-centric compared to the Flutter one, even though you can target web with Flutter as well. Xamarin tends to be extremely enterprise-centric, and, as such, doesn't seem to have a community as much. Beyond some Stack Overflow presence, I don't know of much in terms of a community for Xamarin.

Carl Harroch: Like yourself.

Sebastiano Poggi: Yes. Consultancy.

Hot trends in mobile development

Carl Harroch: Consultancy. Thank you. So, looking to the future is there anything that excites you? I mean, being cross-platform, or just generally in the mobile tech space, is there something that you look at us like this is something you should look out for if you're interested in this subject?

Sebastiano Poggi: So the big trend in mobile native for the past year or two has been declarative UIs And I think that's very interesting, not just in terms of the way that works. It's a model that is very powerful and seems to work very well, but that's beside the point. What interests me is that, curiously enough, this is a model that didn't originate on mobile native. This is something that people doing React Native and Flutter have been doing for a long time. And now, that has kind of permeated into Jetpack Compose on Android and Swift UI on iOS, which curiously were launched pretty much at the same time, probably without knowing that the other was doing the same thing at the same time. And I think that is a very strong signal and happenstance if you want that there is a big shift in the way user interfaces in mobile are handled and that the model proves successful with Flutter and with React Native and is now proving successful on the native side as well.

I think it's very interesting, because, at heart, I'm a person that likes colored things showing up on the screen. So, to me, that's a very big thing and I'm extremely excited about that. Also, I'm a huge Kotlin fan, not because I work at JetBrains but because I like the language, and I liked the language before joining the company as well and having a way to do UI in my favorite language. So I like Flutter as well, which is fairly similar, but I like Dart less than I like Kotlin. So, for me, having the ability to use the very powerful declarative paradigm in the language that I prefer the most is extremely interesting.

And one may be a side effect of this is that I can see over time the discussions on the Android side, native side, and the iOS native side when it comes to UI come closer. Because now, we are not doing things in slightly different ways, but we are essentially doing the same thing. And that may be in the future will allow us to think of native cross-platform, if you will, where, sure, the language you write in and the exact API code you do is different, but the logic is pretty much the same. And that maybe can help move things at the same pace on both sides without having to use cross-platform frameworks. Or maybe this will eventually convince everyone that, you know, what we get from Flutter or React Native is good enough. So we can just do that.

Carl Harroch: I mean, this is probably blasphemy, but you see like...would there be a world in which either, you know, Apple adopt Kotlin or Google adopt Swift.

Sebastiano Poggi: I honestly don't know. I would be surprised personally to see that. I mean, I would be less surprised to see Google making openings towards Swift because they already release libraries for iOS that are written in Swift. I would be very surprised to see Apple do anything that is not Apple. So I don't know honestly if that will happen. But I hope at least as users of those technologies, we will get to have a more similar mindset, and, funnily enough, the same mindset that we can also carry to cross-platform if we need to.

Carl Harroch: Great. Well, thank you very much.

Sebastiano Poggi: Thank you.

Carl Harroch: I think this has been 45 minutes. Thank you so much, Sebastiano Poggi, for going through my questions and sharing your intellect with us.

Sebastiano Poggi: Thank you, Carl Harroch. Always a pleasure.

Carl Harroch: Thank you.