Mohsen Esmaeili

We at Wolt invited Shad Adman to share how they approached Adapting Kotlin Multiplatform (KMP) in Legacy Codebases. It was an insightful session packed with practical lessons, clear explanations, and real-world experience. If you're open to sharing your knowledge with us, we’d love to invite you as well; Just ping me 🤩 Key takeaways: - Cross-Platform vs. Multiplatform: Shad broke down how traditional cross-platform frameworks rely on wrappers, custom rendering engines, and separate VMs, while KMP allows direct access to native APIs (CameraX on Android, AVFoundation on iOS) with no extra UI layer. This means native performance, native rendering engines, and the ability to ship reusable native binaries like JARs, AARs, and iOS frameworks. - Creating a Shared KMP Module He walked us through building a shared module, explaining the structure of commonMain, androidMain, iosMain, and additional source sets. We saw how business logic, networking, models, and rules can be shared and how his team reduced ~20% of duplicated code per platform. - Real Coding Example Shad demonstrated how shared logic is implemented and consumed across Android and iOS, and how third-party tools like Firebase Analytics or Crashlytics can be integrated once and reused everywhere. Thanks again, Shad Adman, for sharing your experience with us! #kotlin #kotlinmultiplatform #androiddev #iosdevelopment #mobiledevelopment #softwareengineering #programming #mobilearchitecture

54

8 Comments

KMP is not an "alternative" to Android Native; it’s the evolution of it. For a while now, Kotlin Multiplatform (KMP) has moved beyond being just a hot trend to becoming a strategic choice in scalable projects. But the question many of my colleagues ask is: Where do we, as Native Android developers, fit into this new game? Should we be worried? My answer is simple: We own this technology. The language, the ecosystem, and the tools of KMP are deeply rooted in the Android world and JetBrains. Why I believe KMP is the best thing that can happen to an Android Developer's growth: 1-Ownership of the Core Logic: Instead of just consuming APIs or rewriting repetitive logic for different platforms, we are now the architects of the Shared Module. We write the core logic once with the power of Kotlin and export it to iOS, Web, and Desktop. 2-Native Power, No Middleman: Unlike many old cross-platform solutions, there are no heavy middle layers or WebViews here. We still have direct access to the native power of each platform, and performance is never sacrificed. 3-Driving Better Architecture: Working with KMP forces you to completely decouple your Domain and Data layers from OS dependencies (like the Android Context). This is a move toward true Clean Architecture—something every senior engineer strives for. Final Thought: KMP didn't come to replace native programming; it came to give us the power to think beyond the limits of a single operating system and create more value as engineers. Your Turn: Has KMP found its place in your teams? What has been your biggest challenge in convincing iOS teams or management to adopt it? #AndroidDev #KotlinMultiplatform #KMP #MobileArchitecture #SoftwareEngineering #SeniorDeveloper #EsmaeeilMoradi

65

3 Comments

KMP is already powering many production mobile apps. Will Skip be the Swift-first equivalent? Kotlin Multiplatform (KMP) made it possible for Android-first teams to share a Kotlin core and ship real iOS apps at production scale. Recently, Skip.tools became open-source and completely free, enabling iOS-first teams to approach the problem from the opposite direction. We’ve already shipped projects using KMP, and it’s earned our trust for production use. Skip looks promising, but for now I’m planning to try it out and see where it goes before recommending it more broadly. If you’ve tried Skip in practice, I’d be curious to hear how it felt in a real project. #iOS #iOSDevelopment #Swift #iOSDev #MobileDevelopment #Skip

103

7 Comments

WaitGroup is leaving us 😞😞😞 With the new Go release, we might not require WaitGroup.Add and WaitGroup.Done. Earlier, to manage goroutines, we had to manually call wg.Add(1) before starting a goroutine and then signal completion with wg.Done(). Now, with the new wg.Go() feature, Go will handle all of that internally. Interestingly, this pattern has existed in the Uber Fx framework since day one 🫡🫡 Curious to hear your thoughts on this shift… Old method var wg sync.WaitGroup wg.Add(1) go func() { defer wg.Done() fmt.Println("go is awesome") }() wg.Add(1) go func() { defer wg.Done() fmt.Println("cats are cute") }() wg.Wait() fmt.Println("done") #golang #waitgroups

72

16 Comments

Big news from testRigor! 🚀 We're excited to announce our partnership with PeerIslands, an AI-Native services company, who will now be bringing our revolutionary generative AI-powered test automation solution to an even wider audience. At testRigor, we’ve been transforming software testing by empowering teams to write test cases in plain English, automatically adapting to UI changes, and eliminating the tedious maintenance of traditional testing scripts. Our platform is already helping organizations speed up releases, simplify testing processes, and enable even non-technical team members to contribute to quality assurance. Now, with PeerIslands on board as our trusted partner, more companies can experience the future of intelligent testing. Together, we're set to make quality assurance more accessible, efficient, and fun, making sure that innovation never takes a backseat. Cheers to a new chapter of collaboration and excellence in test automation! 🎉✨ #Partnership #TestAutomation #SoftwareTesting

248

15 Comments

JVM warmup slowing you down? Explore AOT, JIT profiles, Leyden, CRaC & more to cut startup time, boost Java performance & keep your Java hot with Simon Ritter at dev2next Conference this September! ☕ https://lnkd.in/dVAPUAHk In this session, we’ll look at several approaches to how the JVM warmup problem can be alleviated or even eliminated. Specifically: • Static compilation of Java code ahead-of time (AOT). Specifically, the Graal native image approach • Generating a JIT compiler profile of a running, warmed-up application that can be reused when the same application is restarted, eliminating the need for much of the JIT compilation. This will include details of the work of the OpenJDK Project Leyden. • Decoupling the JIT compiler from the JVM for a Cloud environment. Providing a centralised JIT-as-a-Service allows caching of compiled code and offloading the compilation work when new code must be compiled. • Creating a checkpoint of a running application. This includes all application state (heap, stack, etc.) in addition to the JIT-compiled code. Project CRaC will be used as an example. At the end of the session, you’ll be all set to keep your Java hot! 🔥 🎟️ Secure ticketstoday at dev2next.com 🚀 Use the code JOIN-SIMONR-50OFF for a great discount!  📅 September 29 - October 2. Colorado Springs, CO.

6

POV: How will AI change product teams? 🤔💭 Looking at the current job market for junior devs and QA engineers it is clear that a change is already upon us. AI is becoming more and more capable and integrated in the dev flow. With this we see less need for junior devs and more need for forward leaning senior devs that have a broad T shape as a skillset. AI is rapidly changing how we build and is becoming a more solid part in all parts of the SDLC. From user research and design to development, testing and monitoring. Sam Altman recently said that coding will more resemble playing StarCraft. I think this stands for product development in general and many of the roles we know today will blend together. Regardless if you are new to Software Development or a seasoned pro I think you need to reflect on what this means and adapt to stay relevant. Here is what I think will be important: - Versatility: Understanding various aspects of product development will enable us to contribute more effectively and innovate faster. - Embracing AI: Leveraging AI as a collaborator allows us to focus on creative and strategic tasks, adding more value to our projects. - Passion-Driven Work: With AI handling routine tasks, our creativity and drive become our greatest assets. As we move forward, adaptability and a willingness to learn will be crucial. As well as a deep passion for building. Hating on vibe coding and being stuck in your role will not. #AI #SoftwareDevelopment #Product

28

1 Comment

Developers are losing their minds over no-code tech They feel… - It's oversimplifying tech development - Anyone can build now But many are missing the point entirely No-code is not anti-code. It’s pro-speed. I've been building software companies for years, and I've watched brilliant developers (and teams) spend 9-12months on MVPs that could've been validated in 3 days The goal isn't perfect code It's perfect timing While you're still arguing over syntax, your competitor just launched and started collecting user feedback I’ve seen companies absolutely crush it with no-code: → Marketing spins up campaigns in Webflow → Ops automates entire workflows in Zapier → Sales builds quick prototypes in Bubble → Bloon supports the building of applications in complex, mission-critical environments. The companies winning aren't the ones with the cleanest code They're the ones that ship fastest and iterate smartest As a builder, I care about one thing: Does it work? How you build it is secondary to whether you built it at all

108

68 Comments

We faked a full-blown production incident with a customer to figure out who really owns the code.. 👇 Here’s what went down (and what we learned): This team had almost no documentation. Devs were constantly blocked. And as a result, incidents had spiked. And no one could confidently say who owned what. So we ran an experiment: 🔧 Worked with their CTO & simulated failures for every service in the stack 📞 Spun up a war room call ❓ Asked one question: “Who can fix this right now?” Whoever stepped up, that’s who actually owned it. We documented everything. The results? ⚡ 5 engineers were silently owning huge parts of the system, completely solo 🚨 Several services had zero clear owners It was a bold move, but it worked & in one afternoon, ownership across the codebase was finally visible Not the most scalable approach though, how have others uncovered who truly owns what?

554

257 Comments