DEV Community: ThatsMe,Joana

Finally xcode 26

ThatsMe,Joana — Fri, 21 Nov 2025 12:56:33 +0000

About two weeks ago, I had to switch to a new machine, and I immediately felt the challenges that would come with it. Just when I thought the transition would be tough, my machine updated to Tahoe, which sent me into a panic mode. How would I manage to work in the coming days?

Fortunately, things fell into place, and I was able to successfully update my environment.

What have I done?

First, install xcodes to switch between Xcode versions. I have installed Xcode 26.0.0.

Then updated the following libs:

Kotline Multiplatform plugin: for that, I have followed the version compatibility from this page.
Android sourceset conventions: the first error that I need to fix

build.gradle.kts:123:13: 'fun dependencies(configure: KotlinDependencies.() -> Unit): Unit' can't be called in this context by implicit receiver. Use the explicit one if necessary

And I just need to update according to the conventions.

Replace:

kotlin {
   androidTarget()
   sourceSets {
     androidTarget.dependencies {}
   }
}

by:

kotlin {
   androidTarget()
   sourceSets {
     androidMain.dependencies {}
   }
}

🐞🍀My luck🍀🐞 was on the fact that SKIE is now compatible with Kotlin versions from 2.0.0 up to 2.2.21.
KSP update

Last but not least, I needed to fix the error:
java.lang.NoClassDefFoundError: org/jetbrains/kotlin/konan/target/KonanTarget$IOS_ARM32

I follow this video

Nothing!!!!

I look up on the edge of the internet. And... Nothing!!!!

Until Gemini saw the error and pointed in the right direction

konantarget_iosarm32 is an identifier for the 32-bit ARM architecture target for iOS devices used in the Kotlin/Native compiler and Kotlin Multiplatform projects. It allows developers to compile Kotlin code into native binaries that can run on older 32-bit iOS devices.

Ok! But what does that mean?

The iosArm32 target is now deprecated and unsupported for new iOS app submissions

Ahh! Ok! But How can I solve it?

The error is caused by the removal of the iosArm32 target in newer Kotlin versions (it was deprecated in 1.8.20 and removed in 1.9.20). Although you have updated your source sets, an old reference to the 32-bit target likely remains in your Gradle build scripts or in a cached dependency.

And I cleaned and deleted caches (Just to be sure)!

./gradlew clean
rm -rf .gradle/caches

But nothing! The next step was to check the dependencies.

The error occurring at generateMRiosArm64Main points to an issue with the Compose Multiplatform library or the moko-resources library (if you are using it) trying to generate resources for the now-removed iosArm32 target during the build process for iosArm64.
This confirms that even though your source sets are correct, the resource generation plugin is implicitly attempting to configure all possible iOS targets.

Moko-resources... BINGO

They had fixed a bug in the version that supported the new Kotlin release. Issue

Gemini promtp:

# User: konantarget_iosarm32

`konantarget_iosarm32` is an identifier for the **32-bit ARM architecture target for iOS devices** used in the **Kotlin/Native** compiler and Kotlin Multiplatform projects. It allows developers to compile Kotlin code into native binaries that can run on older 32-bit iOS devices.

(...)

# User: I have updatde kotlin version to 2.2.21 and now can not even compile the project, since I have that error ok arm 32 and my sourcesets are iosArm64 and iosSimulatorArm64

The error is caused by the **removal of the `iosArm32` target** in newer Kotlin versions (it was deprecated in 1.8.20 and removed in 1.9.20). Although you have updated your source sets, an old reference to the 32-bit target likely remains in your Gradle build scripts or in a cached dependency.

(...)

User: It fails here: generateMRiosArm64Main

The error occurring at generateMRiosArm64Main points to an issue with the Compose Multiplatform library or the moko-resources library (if you are using it) trying to generate resources for the now-removed iosArm32 target during the build process for iosArm64.
This confirms that even though your source sets are correct, the resource generation plugin is implicitly attempting to configure all possible iOS targets.

And finally, it worked. And so far so good. But I will continue to update this article if necessary.

However, I have done all this, my IntelliJ continues to complain

[✓] Operating System
[✓] Java
[✓] Android SDK
[✓] Xcode
[✓] Gradle Project

Recommendations:
  ! macOS 26.1+ is not yet supported

This was a joint task with Francisco Cunha, who also helped write this article

A handful of interviews and experiences

ThatsMe,Joana — Wed, 06 Aug 2025 17:36:40 +0000

At the start of forming my team, I was tasked with designing a technical exercise for hiring purposes. It was our first mobile team, and we chose KMP technology. Few candidates have experience in KMP, and we were unsure if they would have the environment ready for conducting a live coding challenge. Besides this technical test, my engineering manager strongly insisted that I assess candidates’ soft skills, including problem-solving, adaptability, creativity, collaboration, and communication.

It occurred to me that evaluating someone's soft skills solely through questions was not an effective approach. Anyone can use AI tools to generate convincing answers that include all the words interviewers want to hear. Who hasn't made this mistake and hired a developer with excellent technical skills, only to find they lack soft skills? I have.

With these considerations in mind, I designed an exercise that simulates a developer’s daily work, comprising a pair programming session with the candidate as the driver and the interviewer acting as a junior developer being mentored. The candidate’s role is to select a task from the backlog and guide the interviewer through its execution. The interviewer's task is to follow instructions, occasionally admit they don’t understand or hear the candidate well, and sometimes disagree with the solutions proposed.

Our primary objective is to observe how the candidate adapts to a new project using new technology, how they employ creativity to solve problems, what questions they ask, how they provide instructions, how they handle frustration when faced with repeated failures, how they debug, and other relevant aspects.

Initially, we emphasise that there are no right or wrong results. We only want to assess how the candidate interacts and integrates into our team. I must tell you, I’ve never seen two candidates follow the same approach even when tackling the same story.

We’ve used this exercise with over ten individuals, and some insights emerged:
1. The candidate rarely asked what had already been implemented or how the feature worked.
2. Worse, they never requested to run the application to verify the code’s functionality or to interact with the solution.
3. Most candidates try to demonstrate their expertise by taking on the most challenging tasks, often leading to frustration and unnecessary coding.
4. Some become paralysed, refusing suggestions to move forward and failing to engage in conversation with the interviewer. It feels as though they are alone in the meeting.
5. When encountering communication or collaboration issues, they never asked if they could take control of the meeting or write in the chat. Only one person lost control and interrupted, claiming it was a waste of time because he wasn’t willing to teach the basics.

The main lessons I learned that I believe may apply to any interview are:
- Never hesitate to ask obvious questions like: “Could you please show me how the solution works?”
- Check the structure of the solution and ask any necessary questions.
- Find out if there are unit tests.
- Ask about the project's libraries.
- Inquire if there’s a business priority or if you can implement what makes you comfortable.
- After these steps, choose a task. Then, after examining the code, explain your plan to everyone. This clarifies your thought process and shows your potential, even if you don’t finish in time.
- Communicate clearly and kindly. If you encounter difficulties, consider alternative methods of communication, such as writing in the chat.

None of the candidates ever completed a task. Now you may ask, did we manage to hire someone? Yes, we have hired excellent developers so far, because completing a task has never been our main goal. For us, the most important thing is to know the people we hire live by the value "Alone we go fast, together we go further".

Discover the wild world of mobile -- Why Choose Kotlin Multiplatform?

ThatsMe,Joana — Mon, 04 Aug 2025 15:50:12 +0000

Whenever a mobile project begins, the first major decision is which technology to select. Should the project use native or cross-platform development? Native offers a clear advantage: access to the latest updates, direct interaction with native APIs, optimal performance and native look and feel. However, adopting a native approach requires two teams to work simultaneously, which increases the chance of discrepancies between the platforms' features, leading to duplication of effort and an increase in maintenance costs.

A cross-platform solution enables the development of an application for multiple platforms, allowing code reuse. However, you may not have immediate access to the latest development tools, you will have limited direct access to native APIs, might need third-party libraries to interact with hardware features, and the final application will likely be less performative than one built with a native solution.

The cross-platform market has two bigger players: React-Native and Flutter. React Native is a JavaScript framework, initially created by Meta and now supported by the community. Flutter is based on Dart and was created by Google. Both require a middle mechanism to connect with native APIs. In the React-native case, it's a JavaScript bridge, and for Flutter, it's a custom engine. I have never worked with Flutter, but I enjoyed working with React-native, despite facing numerous challenges, particularly with styling the UI and a significant dependency on third-party libraries.

Two years ago, I first heard about Kotlin Multiplatform(KMP). Initially, I thought it was a crazy idea to start a new project with a technology that was still in beta phase and a community that was still growing. But we gave it a chance, and so far, we have zero regrets. We don't have a strong dependency on third-party libraries, allowing us to utilise the full platform capacities. We haven't detected any performance issues, and we are using native UI. We encountered issues with iOS crash troubleshooting. The biggest issue yet to solve is how the team with two stacks should organise to avoid code conflicts.

You may wonder what sets KMP apart from other cross-platform options. To start, it doesn't have a middle solution to mediate the communication between the KMP code and the native APIs. The code is compiled into binaries for each platform, JVM bytecodes for Android and native binaries for iOS, allowing interoperability with Swift/Objective-C. KMP can be used in 3 ways:

shared logic: The business logic is shared between platforms by reusing the code, but the UI remains native, Jetpack Compose and SwiftUI. It guarantees that business logic is consistent and reduces the development time. However, it doesn't prevent inconsistencies between UIs.
share a part of logic: It is possible to use KMP just in a small part of the code and integrate with the existing native codebase. This may be used to create critical modules or features, with the same advantages and disadvantages as those mentioned above.
UI and Logic are shared: With Compose Multiplatform, it is possible to have 100% of the code reused, as we have in other cross-platform solutions. This allows us to take advantage of 100% of the qualities of a cross-platform solution, including total reusable code and consistent behaviour, resulting in cost reduction in development and maintenance.

In contrast to the other cross-platforms, we can define the following differentiating points:

Performance: because KMP compiles the code to native and doesn't need a middle solution, it often leads to performance closer to native apps.
native interoperability: KMP offers seamless interoperability with existing native code and direct access to native APIs
Flexible adoption: KMP modules enable the team to select the pace of adaptation, with less risk involved when stepping back (not as much for Compose Multiplatform). For Android, most can be converted to native, while for iOS, the main effort will be on rebuilding the business logic.
Tooling: Both native IDEs, Android Studio and Xcode, can be used, taking advantage of each IDE's features.

Initially, I was sceptical about working with KMP, but now I am convinced I made the right decision by allowing myself to experience and learn from KMP. I am excited to see the community growing as more organisations consider KMP for their projects. I hope my articles about my journey contribute to that growth.convinced that I made the right decision in allowing myself to experience and learn from KMP. I am excited to see the community growing as more and more organisations are considering KMP for their projects. And I hope my articles about my journey can contribute to that growth.

Embark on an Adventure: Your Exciting Roadmap to Mastering the KMP!

ThatsMe,Joana — Fri, 25 Jul 2025 18:08:48 +0000

I decided to set aside my intuition (as I commented in my previous post) for a deep dive into Kotlin Multiplatform. To avoid improvisation, I compiled a roadmap to outline how I will learn KMP.

The roadmap

Kotlin

Kotlin Multiplatform

Kotlin Multiplatform - libs

Android - Jetpack Compose

iOS - SwiftUI

Do you have any other suggestions? Please let me know in the comments.

I'll keep updating as I go. I hope this content can assist you on your journey.

From Pixels to Pocket: Embrace the Thrill of a Mobile Career Change!

ThatsMe,Joana — Fri, 25 Jul 2025 17:44:28 +0000

Almost two years ago, I embarked on a journey. I was living my life, growing up as a front-end developer, and occasionally working on back-end development, when the challenge was presented to me. A new project was arriving, and it was being considered to use Kotlin Multiplatform.

Of course, my first reaction was, "What? Kotlin, what?" In a company full of React developers, why not React-Native? However, after a brief analysis, I was intrigued by this new cross-platform solution. My second reaction was, "Yah! Why not? Why not switch from the React and React-Native world to the Kotlin and Swift world?".

I have been living outside my comfort zone, and this change was just another step beyond it. However, I must be honest, I rely on most of my intuition to survive, and this time was no exception. Initially, it wasn't very easy to adapt to Kotlin. Every time I tried to do a shared logic task, I got overwhelmed, but Jetpack Compose and SwiftUI were a different story, because I could leverage my React experience.

In this time, I managed to learn the basics and contribute to my project. But now is the time to drop my intuition and to start working on learning, practising, failing and going back to the beginning until I manage to do it right.

So it begins my hero's journey, with only one assumption: I failed yesterday. Tomorrow, I am sure it will be different.

How to kill the idea of Perfection

ThatsMe,Joana — Sat, 12 Jul 2025 08:50:57 +0000

If we think carefully about this number, we can immediately feel the amount of work that has to be done to achieve it.

I saw this number for the first time in a quote from a famous illustrator, Walt Stanchfield, who says, "We all have 10,000 bad drawings in us. The sooner we get them out, the better." After learning this quote, I look closely at the painting every time I visit a museum and think about how many bad drawings are behind it.

We can only see the Perfection behind the great master's painting and cannot imagine the long hours of work required to achieve it. However, as science evolved, we discovered that layers of imperfections were hidden behind the Perfection of the paintings.

Reflecting on my work, I realized how far I was from achieving success. I calculated the number of hours I had worked as a software developer and estimated that I had worked almost 20,000 hours. Despite this, I still felt like I was failing all the time. I took some time to think about it and realized that if I had divided these hours by the number of languages and tools I had worked with, I would have worked less than half of the 10,000 hours each.

I did not have a good conscience and was not kind to myself, which led me to pursue Perfection constantly. I fell into a cycle of working long hours on the same task, even putting in extra hours. I overthought every scenario, including the edge cases. My backlog started to grow, and I struggled to accept feedback to improve. My imposter syndrome grew daily, and because I felt like an imposter, I needed to spend even more time on my tasks until I thought they were perfect.

Over the last 18 months, I stopped chasing success and started to learn how to fail successfully.

My initial approach was to apply development methodologies like TDD, test driven development, to my daily life. Instead of going through a lengthy ideation process and complex implementation and presenting it to the world for testing, I started with small tasks. I created a draft, tested it out, and then refactored it. I repeated this process until I achieved the desired outcome. This way, I didn't get stuck in a task without delivering something visible to others. By applying TDD, I was able to create continuous delivery, which allowed me to learn from my mistakes and fail fast. Sometimes, the minimum is enough for what you need. With this approach, you can foster a culture of feedback and avoid overthinking.

For my second approach, I sought out friends who were fearless in providing me with constructive feedback. I shared with them what I was working on, listened to their feedback, and made necessary changes. I also received support from mentors and joined online communities with similar interests. I attended events both within and outside my company to expand my network.

Finding a safe place to test my task was also crucial. I needed a place where I wouldn't be criticized for my mistakes but could teach others what I had learned. It had to be a supportive environment where I could gain the confidence to try and test new things.

To improve my self-knowledge, I decided to take a few initiatives. Firstly, I started practising mindfulness. I took some time in the morning and evening to reflect on my day and learn from it. I also created a journal to keep track of my progress, including my goals and achievements. It's important to acknowledge our accomplishments and not start afresh every day. Additionally, I encouraged a culture of feedback. I welcomed positive feedback as a sign of doing well and viewed negative feedback as an opportunity to learn and improve.

It has been quite a journey so far, and I must admit that I have encountered both successes and setbacks along the way. However, I have learned that whenever I face failure, I feel secure enough to keep trying and not give up. This mindset has helped me overcome my insecurities and enabled me to play a vital role on my new team. I provided valuable input in selecting the right technology, assembling the team, and even learning a new programming language.

But I would like to share one last advice. So, let me ask you: have you ever considered how to kill the idea of Perfection?

This advice was a valuable lesson I learned in Porto. The lesson came to me while I learned about the Palácio da Bolsa, which houses an incredibly beautiful Arab room. The room was designed according to the principles of Arab architecture, which state that only God can attain Perfection and that humans cannot achieve it. To reflect this belief, the architect purposefully introduced an imperfection in the room's design - the main door is slightly off-centre.

After learning this lesson, I began to intentionally add small imperfections rather than strive for unattainable perfection.

Despite my natural desire to do everything perfectly, I remind myself every day that progress is more important than Perfection. By applying these valuable lessons, I have been able to make meaningful steps towards my goals. While the journey may not always be easy, I am committed to pushing forward and achieving my dreams, no matter what challenges may come my way.