We have joined other fellow Go users at GoLang meetup Prague. Here is slide-deck for our short lightning talk.

Discover the importance of integration tests in software development for robust code. Learn how they improve code quality, prevent production surprises, and ensure seamless component integration.

Boosting Code Quality with Integration Tests: Bug-Busting in Software Testing | Showmax Engineering

We all know writing tests can be a bit of a time sink and, well, a tad dull. But, trust us, they're your code's best buds, sniffing out those bugs and keeping your work top-notch. We're here to talk about crafting efficient tests that are quick in bug-busting. Let's get into the nitty-gritty of software testing!

In our CMS team, the most critical parts are API services, especially our lovely Catalogue API, which impacts end users and can easily affect the platform’s usability. Catalogue is the source of nearly all our content, including movies, series, sports events, promoted rows, etc. It supports a wide variety of clients, has a continuously growing number of API versions, and receives a high amount of requests every second. In addition to all of that, Catalogue API uses Elasticsearch indices with a constantly changing mapping as a data source. In other words, it is a perfect environment where bugs can find shelter.

Back in 2021, we had only unit tests for Catalogue. Even though unit tests are great, we realised that unit tests alone are not enough to prevent stressful surprises during production deploys, especially after big cross-service changes. Unit tests typically only work in a limited context on a small section of a program (known as the “unit”). They also heavily rely on mocking things, which consequently brings the extra maintenance costs of keeping the mocks synchronised with the code after every refactor or function rename. 

The main concern is that we can't include all crucial Catalogue parts in the testing loop only by having unit tests. We need something larger or, if you like, higher level. The idea with integration tests is to have the ability to send a request to a Catalogue API, trigger the entire call stack, hit Elasticsearch, and get a response. Another benefit is that integration tests only care a little about the code itself. As a result, we can rename, refactor, and move packages around without the burden of syncing tests. Mocks are not welcome here!

We can configure our CI to spin up Elasticsearch when integration tests require it. We can use pytest to set up a testing application, provide requested fixtures, create Elastic indices, and fill them with data. In turn, falcon's test client can send requests. Sounds straightforward, right? Well, not really. 

We rapidly sketched a testing environment, including the test app setup, Elastic connection and indices creation, various fixtures, and other related tools. The challenge is accurately recreating that constantly changing mapping we have already mentioned. Indices and the mapping are defined by a fabled (and feared) cron job called ES-init, which takes normalized data from our CMS DB, denormalizes it, and indexes it into Elastic. It is a totally different environment.

So how can we get information about the indices? In the first POC, we simply dumped the mapping data into a JSON file and saved it in our integration-test Python package. It worked! We got proof that we could fit all these puzzle pieces together. Now we can write something like this:

#javascript#
@use_data(
    marketing_promos_data=[
        {
            "title": {"eng": "Coming soon Call to action"},
            "promo_type": PROMO_TYPE_SPORT_CALL_TO_ACTION,
        },
        {
            "title": {"eng": "Coming soon Editorial"},
            "promo_type": PROMO_TYPE_EDITORIAL,
        },
    ]
)
def test_no_call_to_action_promos_for_older_clients(
    client_website, main_territories, marketing_promos
):
    # Get all promos. Default API version is 138.
    result = client_website.simulate_get("/catalogue/promos")
    assert len(result.json) == 2
    # Do not return Call-to-Action promos to older clients.
    result = client_website.simulate_get(
        "/catalogue/promos", headers={"Showmax-Int-Api-Major": "130"}
    )
    assert len(result.json) == 1
    assert result.json[0]["title"] == "Coming soon Editorial"


Yes, it's beautiful! It has zero mocks and tests a lot (remember that the request goes through the entire call stack). What is more important is that it's easy to read and write, just look at it.

Let's write some code, and you will see how easily we can request the required data for a test.

#javascript#
def test_something(
    client_android,
    assetflat,
    main_territories
):
    # Some testing is happening here.

The body of this test now can use a ready-to-use Android client, one asset, and all main territories. The asset and main territories documents are indexed in the corresponding indices. All fixtures have reasonable defaults. For example, the assetflat object is a movie with valid license windows for all countries.

Imagine we want to ensure that the /by_id endpoint filters out content which doesn't have a license for a particular country. Easy!

#javascript#
@use_data(
    assetflats_data=[
        {"uuid": "uuid-1"},
        {"uuid": "uuid-2"},
        {"uuid": "uuid-3"},
        {
            "uuid": "uuid-4",
            "license_windows": [
                {
                    "start": choices.DATETIME_PASSED,
                    "end": choices.DATETIME_FUTURE,
                    "countries": ["ZA"],
                    "subscription_statuses": [
                        "sports_full",
                    ],
                    "type": "SVOD",
                    "uuid": "uuid-4-lw_za",
                    "is_downloadable": True,
                }
            ],
        },
    ]
)
def test_filter_by_content_country(
    client_android,
    assetflats,
    main_territories,
    main_languages,
    categories,
    main_ratings,
):
    result = client_android.simulate_get(
        "/catalogue/by_id",
        params={
            "id[]": "uuid-1,uuid-2,uuid-3,uuid-4", 
            "content_country": "KE"
        },
    )
    assert result.status == HTTP_200
    assert result.json["count"] == 3

We can request multiple objects and overwrite only the parts we want. In our case, asset uuid-4 has a valid license window only for South Africa. Other assets have valid license windows for all territories. Similarly, we can overwrite any fixture we want. For example, we've created a helper which allows us to generate hundreds of sports events with any date and time range.

Again, look at the test above – it's self-explanatory.

After we finished writing our first integration test, several developers had already changed an Elasticsearch schema in CMS multiple times. As a result, our Catalogue tests with fixtures based on hardcoded "stale" mappings didn’t make sense anymore. Moreover, such tests would not catch a bug introduced by new mapping changes in CMS. This happened several times during production deployment. Changes in Service A implicitly may affect Service B.

We could ask developers to dump Elasticsearch mapping information and update a JSON file inside the integration-tests package every time it’s changed, but that would require another forgettable and manual step. Is there a way to automate this? 

Yes: having our code in a monorepo gives us this flexibility. We can access files of other services and packages. So we introduced a test for CMS which will fail a CI if mappings are not synced with the integration-tests package. Simple and efficient. You can’t merge your pull request if the integration-tests package has outdated mapping. Period.

Another CMS command, that performs this synchronisation:

What does all this give us? Elasticsearch indices are created and populated with data by the CMS service but are read by the Catalogue API. If even a tiny Elasticsearch mapping change introduced by the CMS service is not fully tested on the Catalogue API, we can end up with a bug in production. Performing these tests manually is nearly impossible since we would have to cover a lot of cases (multiple endpoints, different clients and API versions) and unit tests just aren’t adequate for this. Integration tests solve this problem and work as a glue between different services.

Monorepo not only allows us to access files of other services but also gives us the luxury to install packages from the path. If we change our packages, we don't need to rebuild and push them to PyPI. No need to update poetry.lock files in all dependent services (this topic might be a separate blog post). We simply change the code of the python package, and those changes are reflected in services during the next build. 

During the CI, we know what services or packages were changed, and based on this information, we run tests for those. For example, if a pull request includes changes for CMS service and es-models package (another python package), we run tests respectively for CMS and es-models.

Could we extend this logic so we also run tests for services which depend on changed python packages? Absolutely! All python dependencies are listed in pyproject.toml file. If a changed python package is referenced in service’s pyproject.toml, we add this service to the loop.

How is it related to integration tests? Imagine we want to add one field to the index where all assets are stored. Changes will look something like this:

[CMS service] Elasticsearch mapping change

[integration-tests package] Elasticsearch mapping update

[es-models] Reflecting mapping update in our python wrapper for Elasticsearch

When such a pull request is created, the CI will run the following tests:

Run tests for integration-tests python package
undefined

Run tests for es-models python package
undefined

In this sequence, integration tests ensure that Catalogue, Catalogue-proxy, and Playback will not be broken by changes introduced in CMS.

In conclusion, while unit tests serve as a valuable tool in software development, they are rarely sufficient in ensuring the seamless integration of various components of big projects. This is where it might be beneficial to invest time into creating integration tests that enable us to test the interactions between services and identify potential issues that might arise in more of a “real-world” scenario.

Explore the creative journey of designing swag and cultivating a remarkable culture at Showmax Engineering. Discover how we've built a unique workplace identity that fosters innovation and teamwork

Designing Swag and Culture: Unveiling the Remarkable | Showmax Engineering Blog

As a marketer, it's always a great feeling to see people happy with a product you've helped promote or enjoying the cool stuff you've made to create a buzz around a brand. When it comes to employer branding, it's pretty much the same story. Everything we create is meant for people to enjoy and share. In this look-back post, I'd like to tell you the story of the Showmax Engineering brand and how much we loved working on all the branded stuff that we now see our colleagues wearing or using in the office, at our events, and during their free time.

For five years, Showmax Engineering didn't have a dedicated employer branding manager or a designer to handle the designs needed for online promotions and events. We pretty much dealt with things as they came up. One story I heard was about a hiring event where the team ordered light yellow t-shirts simply because they wanted to stand out. Nobody really cared about the brand colors, which were primarily black with pink and grey accents. 

Showmax team at the COFIT conference back in 2018.

This approach resulted in having several versions of the logo or logo splash, which led to my first mistake when I tried to upload the same logo icon to all our social media accounts. Unfortunately, I ended up replacing the new one on one social network with the old one, which dominated the rest of the networks. We needed to bring some order to the chaos and create a brand guide. It took us a good six months to get there.

The team used two versions of the logo icon and different versions of the logo and the logo icon in the static logo version and its animated splash.

We knew we were building a brand that would hopefully last for years. So, we reached out to Daniel Valčík, our Product Design Solution Lead, to do some research, provide recommendations, and create an inspiration board. Since we were proposing a brand and logo derived from the main Showmax brand but creating a new sub-entity, we needed to sell both the idea and the proposed solution. Fortunately, we made the right choice in picking Daniel to help us, as his recommendation paved the way for success with the central team. So, starting in 2021, we had just one logo. Alongside Michaela Mašková (Míša), our contracted designer, we put together the brand guide. Then, we embarked on the fun part – working on our swag.

Looking back, I can see that the time when we were laying the foundation – the brand, logo, and logo style guide – was a fantastic "incubation" period for Míša and me to get to know the team, its spirit, and its approach to self-promotion (basically, they despise it). The folks at Showmax are genuinely nice, open, and caring about the impact they have on people around them and on the world in general, and they have a fantastic sense of humor. They also, for the most part, love their sports. Knowing this mindset, we approached the swag with a focus on making it practical (no more wasteful items), ensuring high quality, and making sure everything matched well to create a cohesive look.

This is our very own and favorite, soft and warm hoodie.

The new logo allowed us to create a series for various occasions. This one is for alumni, while another one was designed for Showmax teachers.

The reusable party and event cups have two design types.

Weekend or business travel backpack and the cap that comes in handy at the summer offsites.

What we're most proud of, and what kept Míša burning the midnight oil, is the sports set. We designed a softshell jacket, sports t-shirt, headband, and cycling dress, all produced in collaboration with the Lavi sportswear brand. Since everyone's opinion matters at Showmax, we took a vote to pick the best design. Below, you'll find the shortlist of the designs.

And here is the one that emerged as the winner. We call it the Chip design.

The pattern combines a microchip subtly connecting engineering with a runner on the "chip track." Most people ordered the black version, which made us happy since it matched the brand colors perfectly.

The cycling set: headband and the t-shirt (left) and  the runners t-shirt (right).

As the chip design was the most elegant, clean, relevant, and the universal symbol of the engineering team it represented, we used it on plastic cups and all the invites to the sports events, not just on the sports apparel.

Eventually, we also applied the design to the name cards used for reserving a table after implementing a flexible desk policy.

In 2021, our team leaders launched a fantastic initiative: defining the team values that we were already living by but hadn't put down in writing yet. The goal was to keep these values intact, even as the team was rapidly growing and working in a hybrid mode. Through various workshops and discussions with team members, we came up with a set of ten values. Our job was to introduce these values to the team and help everyone (especially newcomers) embrace them. 

First, we took on the challenge of sharing our company's values in a fun way. Since there was a ton of paper used for boring presentations and guides about our values, we decided to save time, energy, and paper by putting our values on stickers. We got inspiration from comics, movies, and the IT world. You can see what we came up with below.

We placed one of the stickers on kids' T-shirts distributed during the Kids' Day at the office.

Next, we thought about how to get folks excited about living these values. We heard some team members talking about fun company pins, so we combined these ideas and created a system to recognize and reward people who embody these values with a pin. It was a more significant task than just creating another branded item, but working with Zita Pivcová (Head of HR) and Anička Hlaváčková (formerly from HR at Showmax) went as smoothly as always. Together, we defined the system, its levels, and how people would collect simple badges and quickly designed the pins to earn a metal pin. You can check out the pin designs below. 

Anyone who collects three of the same basic badges earns a metal pin.

The first pin comes for free when you join Showmax.

Last year brought two new items that we've been thoroughly enjoying. First, we have a sofa adorned with the same patterns you've seen on the pins. We bring it with us to events where we chat with people about Showmax and how we operate. The idea for the sofa came up after a conversation with Daniel, who presented the concept of Showmax as a cinema in our customers' pockets — a cinematic experience accessible from the comfort of a living room sofa. The second exciting addition is our sweatpants, designed after the last wave of COVID-19 and enjoyed during our last offsite in Znojmo.

Designing Swag and Culture: Unveiling the Remarkable Spirit of Showmax Engineering

Discover the remarkable evolution of Android TV development, as we share insights into how innovation, adaptability, and user-centric design transformed our app. Dive into a journey that redefines TV streaming.

Elevating Android TV Development: A Journey of Innovation and Transformation

As engineers, developing a video-streaming app that lets people enjoy movies anytime and anywhere means expanding your reach across multiple platforms. With a limited team, it's crucial to ensure consistent support for development, bug fixes, and features. Prioritizing the most widely used platforms makes logical sense. In this context, the African market takes center stage – it's mobile-first, with users watching content on the go, during commutes, and while traveling long distances.

Previously at Showmax, we faced the challenge of catering to diverse platforms with a single mobile team. This team was responsible for developing mobile apps for both Android and iOS, as well as covering Android TV and tvOS. This approach seemed reasonable due to shared programming languages and potential codebase integration. However, the TV experience, known as "leanback" due to users typically leaning back on a sofa while watching on a large TV screen, brought unique design and product considerations. And unfortunately, the platform’s UX was a bit left behind. 

When we set out to develop an Android TV app, we opted for a simple approach that adhered to industry standards. We built our application using the Android Leanback library.

This widely-used library is officially supported by Android, sparing developers from implementing all views, components, and intricate interactions (think of navigation in a 'touchless' environment). It offers solid system support out of the box.

Designing an app for the TV platform is cost-effective due to existing elements and limited design adjustments.

Due to technological advancements, the library has become somewhat dated, impacting the user experience and necessitating significant adjustments for TV app development.

As mentioned earlier, design and product decisions are constrained by the Leanback library's components and layouts.

One colleague, who is an Android TV owner and enthusiast, aptly pointed out the UX during a redesign demo: "Android TV users are simply used to [visually] suffering when using the apps."

The original Showmax Android TV application was constructed several years ago using components from the Leanback Library.

These challenges, combined with a heightened focus on mobile apps (given their prevalence in African markets) and a lack of dedicated design or product management for the Android TV platform, led us to approach the app as an MVP – a minimum viable product. While supporting new features, we prioritized basic functionality over specific or elaborate designs.

With a commitment to allocate 10 percent of our time to innovation and approximately 30 percent to address technical debt and engineering tasks, we aimed for a more balanced approach. This ensured we weren't solely focused on external demands and features from other teams. Thus, we capitalized on this time to enhance our Android TV app.

Our initial step was a common one – identifying pain points collectively. With developers, testers, and app users, we unearthed numerous minor issues ripe for fixing. These low-hanging fruit were prioritized based on technical complexity and potential impact on user experience. We utilized our technical allocation to incorporate these improvements into our plans. This phase primarily involved resolving UI issues and refining navigation between screens. We conducted A/B tests and drew insights from other platform tests and improvements. Additionally, we integrated sought-after features already implemented by other TV teams. Our focus was on tasks demanding minimal Product or Design involvement, requiring limited effort on our part and no backend changes.

The outcome was remarkably positive – we received favorable internal feedback and users' reviews and questionnaires echoed the improvements.

Following the swift fixes, we tackled more substantial challenges that demanded significant time investments across multiple teams. Since our team wasn't overflowing with resources, including Product and Design teams, we needed alignment with other priorities. At this juncture, before delving heavily into the existing app, we proposed a comprehensive platform overhaul. We faced two options: retain native platform support or port our existing JavaScript-based solution for smart TVs to the Android platform.

The smart TV solution was already in use on the web and various TV brands. Adding the native player, which we already possessed, made it the quickest and most cost-effective choice. Unfortunately, the performance of the ported JavaScript application was underwhelming on regular Android TV boxes, and our smart TV team lacked the bandwidth for performance optimization. The alternative was to proceed with the native approach. While promising a superior user experience and performance, this route required significant investment. Thanks to the positive outcomes from initial changes, available team capacity, and the considerable presence of Android TVs in the market, we obtained the green light for this revitalization effort.

To kick start the process, we brought in a dedicated designer fresh from another project within the company. Additionally, we allocated 30% of one of our Product Managers' time to assist with the project. As the team leader, I dedicated half of my time to this endeavor. Furthermore, we appointed a Lead Android TV engineer from our team to closely collaborate with the group, forming a well-rounded product trio.

In conclusion, our journey toward enhancing the Android TV app involved simplifying the technical approach, tackling challenges incrementally, and nurturing innovation within our team. The outcome was a more refined and user-friendly app that aligned with the unique demands of the Android TV platform.

In our pursuit of enhancing the Android TV app, we embarked on an in-depth research journey. Building upon our initial issue triage, we conducted numerous customer interviews and testing sessions, effectively creating an extensive Design sprint.  (The process of rethinking the solution and opportunity mapping was similar to what we have described in the blog post focusing on data driven design process). Through these efforts, we identified major pain points. However, we realized that many of these challenges couldn't be easily resolved within the confines of the existing Leanback library offered by Google. Addressing them would necessitate substantial investments in new development and a comprehensive app rewrite.

We started by a screen-by-screen analysis of the current solution with gathering feedback from all stakeholders to identify all opportunities.

Recognizing the need for analytical insights, we enlisted the aid of one of our Data Analysts. They assisted in the data crunching required to assess the current solution and support the tests and experiments we were eager to undertake. Armed with a solid justification for additional resources, we found ourselves in a position where innovation knew no bounds. Our platform transformed into a dynamic research lab.

Subsequently, Affinity mapping helped us identify the key ideas and assumptions to prioritize.

Taking a bold step, we bid farewell to the outdated Leanback library that had previously constrained us. This opened the door to entirely fresh designs, whether they involved individual elements or entire screens. Our approach now encompassed a spectrum of innovative solutions, often drawing from successful strategies on similar platforms. This approach led us to pioneer novel navigation methods – some of which were eventually embraced by other TV platforms. Additionally, we refined content promotion techniques and introduced a range of feature enhancements. During this phase, we also embraced a new Design system, a tool that greatly expedited the platform revamp process. Interestingly, while our Android team had hesitated to adopt the Design system for their mobile app due to its established functionality, they eagerly embraced it for the TV app, recognizing its potential as we built it from the ground up.

Finally, we prioritized the solutions based on technical feasibility and user impact using a simple prioritization matrix to determine what to address first.

As our journey progressed, it became evident that our esteemed platform demanded full-fledged attention. In response, we took significant steps to reinforce our efforts. We welcomed a dedicated Product Manager exclusively responsible for Android TV. Simultaneously, we selected a developer from our ranks and elevated them to the role of Android TV platform lead, overseeing all matters related to ATV. The addition of the new Product Manager necessitated a reevaluation of our team's capacity allocation. The outcome was a balanced distribution – one-third for mobile, one-third for TV, and one-third for our team's internal technical initiatives.

In closing, our commitment to research and innovation transformed our Android TV app from a mere platform into a dynamic laboratory of ideas. Through tenacity and adaptability, we ushered in a new era of design, functionality, and user experience, propelling our app to the forefront of modern TV streaming platforms.

The reworked application has a modern appearance, employing custom-built elements and layouts derived from our in-house design system.

Our journey to enhance the Android TV app underscored the value of adaptability and innovation in a rapidly evolving landscape. What started as a quest to improve user experience culminated in a transformative process that redefined our platform's capabilities. By challenging convention, embracing research, and fostering a culture of exploration, we unlocked new avenues for design and functionality. The lessons we learned along the way, the hurdles we overcame, and the innovations we championed have paved the path for a future where the Android TV experience continues to elevate and captivate our users. With a dedicated team, a fresh approach, and a willingness to push boundaries, we are excited to embark on this new chapter of Android TV development, armed with the knowledge that every challenge is an opportunity and every innovation propels us toward excellence. Together, we journey onward, crafting a dynamic TV streaming experience that resonates with viewers in every corner of Showmax’s market in Africa.

Earlier this year, Google introduced a new Leanback library based on Jetpack Compose. We were proud early adopters of this library and are pleased that we could contribute to shaping the future of Leanback development through our participation in Google’s Early Access Program. Without our prior internal efforts to rework the TV platform, this would not have been achievable. You can find more information in our recent blog post on Baseline Profiles for Android or explore our talks on the Android TV transformation and adoption of Jetpack Compose for Android TV.

Enhancing Android TV App Development: A Journey of Innovation and Improvement

Discover Kotlin Multiplatform Mobile (KMP) in our latest blog post authored by David Aldorf (iOS) and Tomáš Král (Android). Explore the benefits, challenges, and performance considerations of this powerful framework for multi-platform app development. Uncover the potential of code sharing and seamless UI development with Compose Multiplatform. Whether you're an iOS or Android developer, KMP offers a game-changing approach to mobile app development. Dive in now!

Exploring Kotlin Multiplatform Mobile (KMP): A Comprehensive Overview by David Aldorf and Tomáš Král

Authorship Disclaimer: This blog post was co-authored by David Aldorf and Tomáš Král.

The realm of multi-platform development has received a remarkable addition with JetBrains' new framework known as Kotlin Multiplatform Mobile (KMM), which has evolved to be Kotlin Multiplatform (KMP) since September 2023. The primary objective of KMP is to facilitate code sharing across various platforms, effectively curbing development costs. In this article, we dive into KMP, its unique features, challenges faced during implementation, and its applicability to real-world projects.

So why did we opt for Kotlin Multiplatform? We were driven by the aspiration to maximize code sharing, and with Compose UI now available on iOS, we chose to embark on this path to achieve our goal. This decision promised not only efficient cross-platform development but also the potential to leverage the modern Compose framework seamlessly across iOS and other platforms.

Popular apps using Kotlin Multiplatform (KMP) in 2023

Kotlin Multiplatform (KMP) extends beyond Android to encompass platforms like iOS, web, and desktop. It unifies a shared codebase for internal API access across iOS, Android, web, and desktop, with a standout feature being its native compilation for each target platform. This is made possible by the Kotlin/Native compiler for iOS and desktop and the Kotlin/JVM compiler for Android. Notably, for iOS, the Kotlin/Native compiler translates Kotlin code into LLVM bytecode, seamlessly integrating with Swift runtime components and resulting in iOS app bundles.

The goal is to write to a shared module and especially to commonMain as much code as possible. This part is shared with all platforms. androidMain and iosMain in the shared module are used for platform-specific code. It is written in Kotlin but it can work with platform-specific APIs and libraries. This is pure magic, especially on the iOS side. androidApp and iosApp modules are standard Android/iOS applications using the shared module as a library.

This PoC was written from scratch and it makes sense to us to have just one shared module/library. But in real life, it is possible to make more of them. For example, one for the data layer, one for data storage, etc. Also, a database-shared module can be used the same way on all platforms regardless if it is Room on Android or Realm on iOS. These platform-specific things will be in the Android/iOS part of the shared module. Android and iOS applications will just call a simple facade API.

We use it just for Android and iOS but it can be used for Web and Desktop as well. JetBrains devs are going even further and their idea is to share the same Domain models and services between Backend and Frontend.

Our goal is clear: to create a prototype app that showcases a grid of movies and series. When users tap on an item, they'll see detailed info about it and be able to start watching. To achieve this, we'll download the assets and make sure users can play videos from their source URLs.

Before we start KMP development, we need to set up Environment and Project. Xcode, Android Studio, and the Kotlin Multiplatform Mobile plugin are essential. A helpful tool named Kdoctor aids in setting up and validating the development environment. CocoaPods are optional, even JetBrains says to avoid them if your project is not using CocoaPods dependencies. Because it is a more complicated setup.

Good information on how to start can be found here: 

https://kotlinlang.org/docs/multiplatform-mobile-getting-started.html

https://www.youtube.com/watch?v=CIZU_NNAZsA&list=PLlFc5cFwUnmxSiLW3xyStFSbEslmUSG3p

https://terrakok.github.io/kmp-web-wizard/

Android Studio has a wizard-driven setup, resulting in separate iOS and Android apps that share a common codebase. Although this setup appears unified and it is good for getting familiar with KMP,. Iin reality, Android app, iOS app, and KMP module/library (which is in our case called shared) will be  in separate repositories. 

You can check this wizard if you want some inspiration for the build.gradle setup. It especially helps with setting up gradle for specific platforms and dependencies.

It is awesome how simple it is to run an iOS app from Android Studio. The iOS one is created and configured the same way the Android one is. All devices from Xcode can be selected as an execution target.

Compose Multiplatform: Unifying UI Development

Jetpack Compose has transformed UI development, especially on Android, offering a seamless and robust solution. Compose Multiplatform takes this innovation a step further, extending its benefits without drawbacks. It empowers developers to craft captivating interfaces seamlessly on Android.

For iOS, Compose Multiplatform employs Skiko for a unique Canvas-style interpretation, breathing creativity into UI development. While it differs from the UIKit-based approach, it ensures UI interoperability via iOS widgets/UIKit and SwiftUI. By embedding native UI components in shared UIs through elements like UIKitView and ComposeUIViewController, platforms blend effortlessly.

Notably, Compose Multiplatform doesn't cover tvOS, but Kotlin Multiplatform (KMP) remains reliable here. This demonstrates KMP's flexibility in diverse contexts.

For an in-depth look, explore the Compose Multiplatform GitHub repository, a hub of collaborative innovation driving cross-platform UI development.

There are a lot of multiplatform libraries available these days, so you can easily avoid platform-specific implementation. Still, there is room for improvement. In our case, the library for the video player was missing. Even so, the number of KMP libraries is growing every day.

From an iOS developer's viewpoint, adopting KMP can entail a shift to a new IDE (Android Studio), potentially complicating the entry process. While syntax similarities might ease the transition, debugging in Xcode and adapting to Compose's alpha stage on iOS could present challenges. Business logic and networking layers are prime candidates for code sharing, whereas platform-specific concerns often linger.

Android developers have it way simpler. The only big differences between pure Android and KMP projects are build.gradle and project modules structure. Even Compose UI stays almost untouched.

To call a platform-specific API in the shared module, it is necessary to step out from commonMain to androidMain and/or iosMain. It is possible to do it simply by Interface or the new JetBrains construct expect/actual can be used. Expect/actual will force programmers to implement new features on all platforms. To use it, just annotate the desired value, variable, function, or class in commonMain by expecting the keyword to tell the compiler that the actual implementation will be in the platform-specific part of the shared module. Then annotate the real implementation with ‘actual’ in androidMain and iosMain.

In this case the Android app uses ExoPlayer. We used an Exoplayer with MediaSource and AndroidView to be able to use it in Compose.

Navigating the iOS landscape introduces some complexities, yet KMP comes to the rescue. We tap into iOS internal APIs like Foundation, UIKit, AVFoundation, and SwiftUI, and here, KMP lends a hand by allowing us to utilize these APIs through Kotlin. For instance, we opted for AVPlayer. The process is relatively straightforward: we initialize AVPlayer much like on iOS, with the only distinction being the encapsulation within a UIKitView.

In such cases, the Alpha version of Compose Multiplatform introduces a prototype for seamless UI interoperability. With UIKitView, you can easily integrate advanced platform-specific elements such as maps, web views, media players, and cameras into your shared user interface. Conversely, through ComposeUIViewController, you can smoothly incorporate Compose Multiplatform screens into your SwiftUI-based iOS applications, making the transition to Compose Multiplatform a gradual and convenient process. In this case, you can use Compose Multiplatform alongside your current UI layer. You can read more about it in this article: Compose Multiplatform for iOS Is in Alpha.

While KMP excels in facilitating multi-platform development, it's essential to note that iOS compile times might experience a slight increase during KMP app development within Xcode. Therefore, the run-time seems the same as a native app.

While KMP presents a seamless approach to multi-platform development, it does come with some challenges. Debugging on iOS involves separate debuggers for iosApp and shared components. Setting up Xcode Command line tools and integrating CocoaPods might get complicated. Finding help online (StackOverflow, etc.) can be tough since KMP is relatively new. Finding a solution may require going through public repositories.

Kotlin Multiplatform, now called Kotlin Multiplatform (KMP), offers a revolutionary way to build apps for multiple platforms. It lets you share code and easily connect to internal APIs, making development efficient and cost-effective. However, using it for full multiplatform UI development can be challenging, especially on iOS, where Compose Multiplatform is in its early stages, and tvOS is unsupported. KMP excels at sharing business logic, data layers, and domain models, making testing simpler. We recommend giving it a try and gradually integrating it into your project, starting small, and not needing a major code overhaul. You can begin with one feature or API calls and expand from there to share more code with your fellow developers. The key is that you don't have to rewrite everything at once to benefit from KMP.

Exploring Kotlin Multiplatform Mobile: A Comprehensive Overview

Go in Showmax

You might be interested

Integration Tests

Designing Swag and Culture: Unveiling the Remarkable Spirit of Showmax Engineering

Enhancing Android TV App Development: A Journey of Innovation and Improvement

Exploring Kotlin Multiplatform Mobile: A Comprehensive Overview

Integration Tests

Designing Swag and Culture: Unveiling the Remarkable Spirit of Showmax Engineering

Enhancing Android TV App Development: A Journey of Innovation and Improvement

Exploring Kotlin Multiplatform Mobile: A Comprehensive Overview