Objective-C and Swift offer strong interoperability, making mixed codebases a practical and effective approach for large, complex applications.

Importing Swift into Objective-C

Xcode automatically generates an interface for the Swift files and a Swift header for the Objective-C files. Swift classes marked with @objcMembers or types annotated with @objc can be accessed from Objective-C, just by importing the Swift header in the implementation. A similar interface is generated for Objective-C files that can be used from Swift. Please check out this artcle to learn more about the Xcode generated interfaces. This approach has some drawbacks:

1. The generated header cannot be included in other headers.
2. The generated interface is not well organized and seasoned Objective-C developers use the interface as secondary documentation. For example here is how a typical generated interface looks like.
3. Classes marked with @objc still contain Swift vtables and other Swift-specific data. Objective-C compiler does not fully understand them, so these operate with limited capabilities. Objective-C classes also cannot subclass them.

How Swift 6.1 solves these issues?

Swift 6.1 allows the use a Swift implementation with the Objective-C header file. For more information, please download this sample Xcode project and open the Cat.h file.

We declared the interface in Objective-C with a class Cat and a category Cat (Actions).

Here we completely eliminated the .m file, and the implementation for Cat and Cat(Actions) is written in Swift. Also, please note that we are also able to subclass AfricanWildCat from Cat.

We now have the flexibility to implement just a specific class or a category from the header file. The methods defined in the Swift extension are called member implementations. The compiler forces us to implement all the member implementations for the chosen @interface. The member implementations should be non-final and non-overrides, and can have an access modifier of open, public, package, or internal. The extensions of the main class can also contain methods and properties other than member implementations. The nonMemberImplementation method is an example in the code snippet above. Also non-category extension using @objc @implementation extensions may contain stored properties, that can be final (can be accessed only from Swift), have overrides, or access scope of private or fileprivate.

The declarations in the header stay unchanged. Objective-C clients can subclass, swizzle, and interact with the Swift-backed implementation just as they would with a normal .m file. Runtime behavior stays intact.

A few caveats to keep in mind:

• You cannot declare new conformances inside these extensions.
• Method signatures must match exactly.
• Stored properties are allowed, but only when implementing the main interface (not categories).
• final members and Swift-only helpers are excluded from Objective-C by default.

Conclusion

It is worth noting that this feature isn’t trying to solve every problem just yet. Factory methods, lightweight generics, and objc_direct methods still require traditional Objective-C. But those are niche cases. For 90% of use cases—standard classes, categories, and properties — this feature will cover your needs.

Adoption is simple. You can retain your .h files as they are, use bridging or umbrella headers to make them accessible to Swift, and start integrating components gradually. The process is steady, reliable, and transparent.

Swift’s goal has always been safety and simplicity without compromising power. With this update, Swift gets closer to that ideal for mixed-language development. Whether you’re building a framework shared across several apps or modernizing a legacy project, this new capability should make your path forward easier and more maintainable.

References

• Swift Evolution Proposal SE-0436
• Swift 6.1 Release Notes
• Michael Tsai Blog Post
• Understanding Objective-C to Swift Interoperability Using Xcode-Generated Interfaces
• https://nshipster.com/direct/

Objective-C Implementations in Swift was originally published in Swiftify on Medium, where people are continuing the conversation by highlighting and responding to this story.

Swift 6 New Features

Apple is planning to release Swift 6 in September 2024, alongside Xcode 16. This will be the first major Swift update in five years since Swift 5. This release will be on the 10th anniversary of Swift. Over the years, Swift has evolved significantly, from a mere improvement over Objective-C to a safe, multi-paradigm, and performant language that is easy to use.

Apple had previously mentioned that there would be a succession of
Swift 5.x versions introducing incremental changes and new features to pave the way for Swift 6. The major goals mentioned were to improve concurrency support and the memory ownership model. At this point, these have been achieved to a great extent.

Let’s quickly recap the evolution of Swift 5.x versions over the years.

Swift 5.1 (Sept 2019) added opaque return types (foundation feature for SwiftUI) implicit returns, and module format stability.

Swift 5.2 (Mar 2020) brought features like key path expressions as functions, and improved diagnostics.

Swift 5.3 (Sept 2020) brought various language improvements, such as multi-pattern errors catching, multiple trailing closures (which led to significant improvements to SwiftUI APIs), and Swift Package Manager improvements.

Swift 5.4 (Apr 2021) added support for multiple variadic parameters in functions, and result builder.

Swift 5.5 (Sept 2021) was a massive update, bringing concurrency-focused features like async/await, async sequences, structured concurrency, actors, global actors, and Sendable protocol/closures. It also enables the long-awaited interchangeable use of CGFloat and Double types. This update laid the groundwork for other concurrency-related updates in subsequent versions.

Swift 5.6 (Mar 2022) further improved concurrency and language refinements like type placeholders and existential Any. It also added plugins for Swift Package Manager.

Swift 5.7 (Sept 2022) introduced shorthand syntax for unwrapping optionals, Swift Regex, improved interoperability with C APIs, concurrency improvements, and also features a smaller and faster standard library.

Swift 5.8 (Mar 2023) relaxed limitations on variables in result builders, improved implicit self, and allowed back deployment of functions.

Swift 5.9 (Sept 2023) enhanced generics with value and type parameter packs (which eliminated the 10 view limit in SwiftUI), added macros, improved control flow with if and switch expressions, and added the ability to discard task groups.

Swift 5.10 (Mar 2024) closes all known static data-race safety holes in complete strict concurrency checking. It introduces strict concurrency for global variables which prevents data races when using global and static variables. It also brings in isolated default value expressions which closes a data-race safety hole that previously permitted isolated default stored property values to be synchronously evaluated from outside the actor.

Swift 6 will build upon this base. Let’s dive into its most noticeable features.

Expression macro as caller-side argument

User-defined macros can now be used as a default argument, just like built-in macros. When user-defined macros are used as default arguments they are expanded at the call site; whereas when they are used as sub-expressions of default arguments, they are expanded at the place they are written. For example, consider the following functions using the #MyFileID macro.

Here is how the macro is expanded when it gets called from the app code.

Pack Iteration

Swift 5.9 introduced parameter value and type parameter packs, which made it possible to write generic functions that accept an arbitrary number of arguments with distinct types. The most noticeable impact was that the 10 view limit in SwiftUI is removed. With Swift 6, we can now iterate over a value pack with for-in loops. This is an advanced feature of Swift and it may significantly impact SwiftUI APIs.

Typed throws

Errors in Swift are always type-erased to any Error, which encourages writing generalized error handling code. Once SE-413 has been implemented, functions and closures can throw concrete error types.

count(where:)

The count(where:) method lets us easily count elements in a sequence that meets a specific condition, eliminating the need to use filter or reduce methods followed by count, which creates an unnecessary intermediate array.

128-bit Integer Types

New Int128 and UInt128 types are added, expanding the ability to work with large numbers, which is great for large numbers and cryptography.

Conclusion

The release of Swift 6 is a great milestone for converting your Objective-C apps to Swift, if you haven’t already done so. Switching to Swift allows for the use of brand new frameworks like SwiftUI, SwiftData, RegexBuilder, Algorithms, etc., which makes developing apps faster and easier.

According to “The State of Developer Ecosystem 2023” survey by JetBrains, “Objective-C is objectively retired”. Objective-C has lost two-thirds of its users in the last six years, and in the past year only 2% of the respondents used it in 2023. Also, according to this study on Apple’s use of Swift and SwiftUI in Apple’s binaries, the usage of SwiftUI grew by 70%, while Swift usage grew by 50% from iOS 16 to iOS 17.

It is clear that the community of Objective-C developers is shrinking, and Apple is gradually gravitating toward Swift in their internal binaries; hence it is a good idea to start migrating to Swift. Migration to Swift also allows for the adoption of SwiftUI and enables your apps to target all Apple platforms.

References

Apple’s use of Swift and SwiftUI in iOS 17
On the road to Swift 6
SE-0422: Expression macro as caller-side default argument
SE-0408: Pack Iteration
SE-0413: Typed throws
Swift Changelog
The State of Developer Ecosystem 2023
What’s new in Swift?

What’s new in Swift 6? was originally published in Swiftify on Medium, where people are continuing the conversation by highlighting and responding to this story.

We are happy to announce that the Storyboard to SwiftUI converter now produces a SwiftUI project that compiles and runs out of the box.

Here is how we convert a storyboard from the Calculator project to SwiftUI.

Unlike the previous version that combined all output into a single file, the converter now generates a full Xcode project where the source code is organized into groups (Views, Helpers, Models, etc):

• The Views group contains the SwiftUI views.
• The Helpers group contains the extensions required by the SwiftUI views.
• The Models group includes the data models (which will be present if the storyboard contains a UITableView or a UICollectionView).

You may check our updated converter here. It is free to use for files under 10 KB. We recommend converting smaller XIB and storyboard files to SwiftUI first, thus incrementally converting your project to SwiftUI.

We would love to hear your feedback and suggestions.
You can connect with us on Twitter, LinkedIn, Facebook, and GitHub.

Storyboard to SwiftUI Converter Producing a Ready-to-Run Xcode Project was originally published in Swiftify on Medium, where people are continuing the conversation by highlighting and responding to this story.

As an iOS developer, I’m always looking for tools that can help me improve my workflow. Over time, some of these have become absolute essentials in my arsenal of applications, and here they are.

1. Cleaner for Xcode

If you’ve used Xcode, you know that it’s notorious for eating up disk space. This is particularly true when you update to a newer version of Xcode, because many old files that are no longer required are leftover. This app helps remove unwanted and deprecated files associated with Xcode. It can also clean up all derived data and caches and free up disk space.

‎Cleaner for Xcode

2. Rectangle: A Window Manager

Quite often, using multiple apps is a necessity. Although window management on Windows is excellent, it could use some enhancements on a Mac. Rectangle steps in to improve window management with keyboard shortcuts and snap areas. I’ve relied on this application, as well as its predecessor, Spectacle, for years, and they’ve proven to be extremely useful for multitasking.

Rectangle

3. SF Symbols

With SF Symbols, you can incorporate a vast and expanding range of icons into your applications. The best part is that the library keeps growing every year, so you’ll always have fresh icons to work with.

SF Symbols - Apple Developer

4. Sigma

Sigma, a nifty Figma plugin, is a game-changer for iOS developers that automatically generates SwiftUI code from your designs. I personally haven’t used it much, but with my limited testing, I think it works fine. This time-saving tool can streamline the design-to-development process, and I expect it to be a good time-saver.

Figma

5. Amphetamine

This one’s pretty straightforward. Amphetamine keeps your Mac awake, which is perfect during presentations and when you’re running the Macbook in clamshell mode without connecting your laptop to a power source.

Amphetamine App - App Store

Xcode tips for iOS developers

Preventing Typos in Xcode

You can prevent typos across functions and variable names by turning on the spell-checker in Xcode. To turn it on, go to Edit > Format > Spelling and Grammar > Check Spelling While Typing.

You can dive deeper into this by following this blog by Sarunw.

Adding a Single AppIcon Image Asset

If you’re using Xcode 14 or later versions, you can now use a single 1024*1024 AppIcon for iOS and WatchOS targets.

Code Completion with Optional Parameters

You can enable code completion for optional parameters by using Option ⌥ with return ↵.

Dock tips for iOS developers

How I’ve customized my dock:
1. Moved the dock to the left since the screens are vertically smaller.
2. Minimized windows using Scale Effect. This depends on personal taste, and I find that the animations are quicker and crisp.
3. Set the dock to hide automatically. It automatically frees up screen space when the dock is not needed.

You can hide the dock faster using this command from the Terminal:
defaults write com.apple.dock autohide-delay -float 0; defaults write com.apple.dock autohide-time-modifier -int 0;killall Dock

This can be undone using the following command:
defaults write com.apple.dock autohide-delay -float 0.5; defaults write com.apple.dock autohide-time-modifier -int 0.5 ;killall Dock

And we’re done!

What are some of your go-to applications from your iOS development workflow? Let me know in the comments below!

If you’ve made it this far, we’re building an incredibly diverse collective of engineers, designers, and product folks at Tarka Labs.

Check us out 👉 https://tarkalabs.com/about

5 essential tools and tips for iOS developers was originally published in Tarka Labs Blogs on Medium, where people are continuing the conversation by highlighting and responding to this story.

A Virtual Private Network (VPN) creates a secure connection between a user’s device and the VPN server by encapsulating data packets in an outer packet using a tunneling protocol. Once the data packets reach the server, they are decrypted and forwarded to their destination on the internet.

Why do some service providers disallow VPN Use?

The reasons may vary.

1. Banks may block VPN connections due to security concerns since they can hide a user’s IP address and encrypt their traffic, which cybercriminals normally use to evade detection.
2. OTTs often ban VPNs use due to regional content licensing agreements, varying government laws, and censorship. VPNs can help users bypass content restrictions, leading to legal and ethical concerns for OTTs.
3. To prevent users from subscribing from countries where the subscriptions are cheaper.

How can we detect VPN Usage?

VPN use can be detected both on the server and client sides. Let’s first explore how VPN detection can be done on the server side:

• Check against a list of public / paid VPN Servers IP addresses.
• Analyze the incoming traffic. If you can find a large number of users with the same IP address, then it’s probably a VPN server.
• GeoIP tracking — the user’s location and last login date is analyzed. If there is an unrealistic change in the user’s location in an unrealistic timeframe, it could indicate VPN usage.

VPN detection on the client side is more straightforward since the data is encrypted on the client side using a tunneling protocol. On the client side, you can check the Network Proxy settings to check if any tunneling protocols are being used.

How to detect VPN usage in iOS (Swift)

By reading the network proxy settings, you can manually check if tunneling protocols are used. For this, you can use the following code snippet:

In the above code snippet, CFNetworkCopySystemProxySettings is a low-level API that returns current internet proxy settings as a CFDictionary. You can cast this to an NSDictionary and check if any of the tunneling protocols, i.e., tap, tun, ppp, ipsec, utun are in use.

How to detect VPN usage in Android (Kotlin)

In Android, you can check if the active network is using a VPN by the following code snippet:

ConnectivityManager is an Android API to manage network connections. It provides methods to check the availability and status of network connections and request and configure network connections. You can use ConnectivityManager to get the network capabilities of the active network. You can then check if the VPN transport protocol is being used.

How to detect VPN usage with Flutter (Dart)

In Flutter, the approach is similar to iOS. You can manually check if any of the tunneling protocols are in use:

Retrieve a list of network interfaces - a NetworkInterface represents an active network interface on the current system. You can then check if any of the interfaces have names that contain tun, ppp, and pptp, which are commonly used in VPN connections.

How to detect VPN usage with React Native

React Native leverages the platform-specific code discussed above to get the network configuration and detect if a VPN is being used. This can be done by using the react-native-vpn-detect package.

So there you have it!

VPN detection is super straightforward on native Android, purely because you don’t have to manually check for tunnelling protocol names in your network proxy settings. Almost all other frameworks manually check for tunnelling protocol names, which can break if the user uses a different tunnelling protocol. These checks can easily break if new tunnelling protocols are added or the APIs change.

Hi! I’m Ibrahim, an ex-operations executive turned innovative iOS developer. Currently, I’m creating cutting-edge experiences @ TarkaLabs and love to geek out on the latest tech stacks.

The ultimate VPN detection guide for iOS and Android was originally published in Tarka Labs Blogs on Medium, where people are continuing the conversation by highlighting and responding to this story.

Kotlin Multiplatform enables you to maintain a single code base for your business logic across mobile platforms (Android and iOS). This is very interesting because there are not many tools out there that helps to unify business logic across platforms.

What did we build?

We built a simple Expense Tracker Application using KMM, Jetpack Compose, and SwiftUI. The KMM module stores the expenses in a local database and exposes an interface for the iOS and Android apps. Here are some of our findings:

Interoperability issues between Objective-C, Swift and Kotlin

As the Kotlin compiler creates an iOS framework with Objective-C bindings for the underlying Kotlin code it causes several problems. For example, Kotlin enum are translated to an Objective-C object with the cases added as properties.

For the enum above values() returns a KotlinArray<Category>, which does not conform to Sequence. This can be fixed by converting the KotlinArray to List on the Kotlin side using this approach.

We can use an extension on KotlinArray but we cannot use generics in that extension as KotlinArray uses some lightweight generics in Objective-C which cannot be used with Swift. So we wrote an helper class that converts KotlinArray to Array<AnyObject> using Generics:

Redundant Protocol Conformance for SwiftUI

When using SwiftUI, we had to add redundant protocol conformance to Expense so that we can use it to bind to a List.

Library Dead-code Elimination

We used kotlinx-datetime and explored if we could make an Instance object from epoch milliseconds. We could not create an Instance object from epoch milliseconds on the iOS side as the tooling had stripped the required constructor function. The recommended solution is to export the library, but this might increase the compilation time and the binary size. Learn more about this here.

Limited Coroutine support in iOS

Working with coroutines from Swift is tricky as out of the box suspend functions do not have cancellation support, and Flow only has collect function. To solve this we used KMP-NativeCoroutines that converts Kotlin Coroutine to swift equivalents i.e. async-await or Combine.

Like all cross-platform frameworks, KMM has its pros and cons.

It took a significant amount of time and effort to set up initially. When compared to other cross-platform mobile frameworks, community support is not very substantial, and there are no established guidelines for project architecture or design. However, with a collaborative and cross-functional team, we were able to share much of the business logic using proper abstractions.

KMM’s performance is comparable to that of a native app, and the development experience for Android developers is similar to that of developing a native Android app, though it may be unfamiliar to iOS developers at first.

Conclusion

As a relatively new framework, the tooling, community, and best practices around KMM are not yet well-developed. Nonetheless, as more developers and companies adopt KMM, these areas are expected to improve.

KMM can be a good fit if the mobile development team is cross-functional and exposed to Android and iOS. Also, expertise in Android is required as the tooling and the ecosystem is very similar to native Android development. Many companies like Careem, Netflix, Square, etc. are using KMM in production, but we recommend that teams should build a small application in KMM before committing to the framework.

Special thanks to @kalpeshp03 who worked on this project with me.

References

1. Netflix Tech
2. Careem
3. Kotlin Multiplatform Mobile Case Studies
4. Create a Kotlin/Multiplatform library with Swift
5. What We Learned Using KMM For iOS

Hi! I’m Ibrahim, an ex-operations executive turned innovative iOS developer. Currently, I’m creating cutting-edge experiences @ TarkaLabs and love to geek out on the latest tech stacks.

We Tested Out Kotlin Multiplatform Mobile (KMM). Here’s Our Take. was originally published in Tarka Labs Blogs on Medium, where people are continuing the conversation by highlighting and responding to this story.

At Swiftify, we are keen on tracking the evolution within Apple’s development ecosystem. We recently studied the top 100 applications on the App Store to analyze the usage of Swift. After that article, some users naturally asked how many apps in the App Store use SwiftUI?

There are no previous studies on the usage of SwiftUI in apps on the App Store. However some studies look at the usage of Swift and SwiftUI in Apple Frameworks inside iOS 15 and iOS 16. In iOS 16, Swift usage has increased from 12.8% to 18.5%, and SwiftUI usage (when compared to UIKit) has increased from 7.3% to 12.6%.

Results

According to our analysis made in late 2022, out of the top 100 non-game App Store apps (ordered by revenue), 69 apps used SwiftUI. We cannot be sure if all these applications use SwiftUI in the main binary or in a library. But these results are more than we had expected.

Methodology

To determine whether an app uses SwiftUI, we downloaded the top 100 apps on an iOS 15 device, decrypted them using the ipsw tool, and searched for references to SwiftUI by searching for /System/Library/Frameworks/SwiftUI.framework/SwiftUI substring.

Please note since the introduction of widgets in iOS 14, many apps with a deployment target of iOS 14 and above might have some SwiftUI code just for the widgets.

Conclusion

Our findings suggest that 69% of all the applications and 90% of applications with a deployment target of iOS 14 and above use SwiftUI directly or depend on libraries that use SwiftUI. The usage of SwiftUI will increase as watchOS Storyboards have been deprecated in Xcode 14. So we can safely assume that SwiftUI is indeed the future of development on the Apple platforms, given that Apple is constantly pushing for its adoption.

Data

The result of our analysis can be found here.

How many apps use SwiftUI? was originally published in Swiftify on Medium, where people are continuing the conversation by highlighting and responding to this story.

Smartphones have become indispensable, with the average US adult having a screen time of roughly 4 hours daily. In addition to this, 58% of global web traffic comes from mobile phones. Over the years, smartphones have become very capable and efficient to the extent that hardware technologies developed for mobile are finding their way into desktops and laptops like the Apple M1 chips. As of writing, there are roughly 3.5 million apps on the Google Play Store and nearly 2 million on the Apple App Store.

Let us explore some non-native mobile application development frameworks in 2024.

Flutter is an open-source cross-platform UI toolkit for developing highly performant mobile, desktop, and web apps.

Advantages of using Flutter:

1. Flutter uses its UI rendering engine (SKIA) and provides a consistent UI with pixel-perfect UI rendering. Hence, the applications look almost the same on different operating systems.
2. Flutter provides near-native performance because of Dart’s ahead-of-time compilation, and the Flutter engine’s Dart-to-Native communications use faster binary memory buffers.
3. Flutter is growing in popularity with a great community of developers and provides hot reloading, improving the developer experience.
4. Dart is the language to program in Flutter and has a mild learning curve.

Disadvantages of Flutter:

1. Inferior experience for iOS apps due to animations jank. Also, the Cupertino widgets are not updated frequently. As of writing, the date and time pickers introduced in iOS 14 are still not supported in Cupertino widgets.
2. The apps lack the native look and feel as Flutter does not use the system UI components. When developing with Flutter, you get a Flutter app, not a native iOS or Android App.
3. The application size for the most straightforward Flutter app is around 4MB for Android and 10 MB for iOS.
4. The framework is relatively new, and a limited number of third-party libraries exist.
5. Platforms like tvOS, watchOS, CarPlay, or Android Auto are not yet supported.
6. The popularity of Dart is low, and it isn’t easy to find the right talent.
7. Since the framework is constantly evolving, there are possible interoperability issues between different packages using different versions of Flutter.

We recently analyzed the top 100 apps on the AppStore to find out the number of applications using Swift. While studying this, we also examined the usage of Flutter and found that none of these applications use Flutter. This is not surprising, as it is a relatively new framework. The top applications on the App Store are from well-established companies with significant resources, which may be more inclined to stick with tried-and-true technologies rather than experimenting with newer ones.

React Native is a mature, open-sourced, cross-platform app development framework from Facebook.

Advantages of React Native:

1. React Native uses JavaScript, so the talent pool is quite large. Also, a web developer with React experience can easily pick up React Native.
2. Over-the-air updates/code push updates, which can provide updates or patches to the app without going through the app store release process
3. React Native renders the native UI elements, making the apps look and behave like native iOS and Android apps.
4. Supports other platforms like tvOS, watchOS, CarPlay, and Android Auto.

Disadvantages of React Native:

1. You have to rely on many external libraries and open-source maintainers.
2. Knowledge of native platforms is required to be a practical React Native developer in a production environment. You need to know that some iOS and Android development knowledge is required for real-world applications.
3. The project is hard to debug as the error messages are pretty obscure.
4. A React Native app is computationally expensive, the JavaScript code runs inside a JavaScript engine, and the JavaScript context communicates via a bridge with the native code (native host app), which leads to a performance hit on low-spec mobile phones.

Qt is open-source software for creating cross-platform applications for Linux, Windows, macOS, Android, iOS, or embedded systems with native capabilities and speed. It provides its custom rendering engine, just like Flutter.

Advantages of Qt:

1. The platform is relatively mature, battle-tested, and has been around for 26 years, and the core developer documentation is quite good and detailed.
2. It is a perfect option if you have to support multiple platforms like mobile, desktop, and embedded systems. It can run almost anywhere where C++ is supported.
3. Since the core of the application logic is in C++, it is a good option if your team is proficient in C++.
4. Mature third-party C++ libraries can be used.

Disadvantages of Qt:

1. C++ has a steep learning curve, making it difficult for developers without a C++ background.
2. Mobile is not a priority for Qt, and the tooling is more geared towards desktop development.
3. The community of Qt developers developing non-gaming apps is small, so there is a lack of plugins, libraries, tooling, etc.
4. Since Qt uses C++, it is not directly interoperable with Swift.

Xamarin is an open-source mobile app platform for building native and high-performance iOS, Android, tvOS, watchOS, macOS, and Windows apps in C#.

Advantages of Xamarin:

1. Xamarin uses C#, a feature-rich and popular language backed by Microsoft.
2. Since Xamarin is the oldest cross-platform framework, it has excellent developer documentation and is easy to pick up.
3. Existing .NET code (typically from your backend implementation) can be reused in mobile projects to shorten development time.
4. It is a Microsoft product; therefore, there will be long-term support and periodic updates like (.NET MAUI).

Limitations of Xamarin:

1. It takes some time for Xamarin to integrate the latest OS updates, so the developers have to wait until they can update their apps.
2. Some platform-specific knowledge is required.
3. The community support is not very good.

Kotlin Multiplatform Mobile (KMM) is an SDK for cross-platform mobile application development developed by JetBrains. Kotlin Multiplatform Mobile simplifies reusing parts of code that previously needed to be written multiple times, like making network requests, storing data, and other business logic.

Advantages of using KMM:

1. The apps have full access to Native libraries and UI and are consistent with each platform’s design guidelines. KMM is typically used in a way that’s cross-platform for business logic.
2. Since Android developers are already familiar with Kotlin, they can get started easily. Also, Kotlin can be easily adopted by iOS developers developing with Swift.

Disadvantages of KMM:

1. Many components are in the early stages of development and can break in the future.
2. Requires a cross-functional team working with Objective-C / Swift and Kotlin. Also, iOS developers must learn a new language, build system, IDE, and tooling.
3. KMM cannot import pure Swift modules. A Swift library can be used only if its API is exported to Objective-C with @objc, because KMM uses cinterop to support Apple frameworks under the hoods, and can create bindings only from C / Objective-C headers. So the Swift APIs need to be annotated with @objc so that they have an Objective-C generated interface.

Capacitor is a new open-source hybrid app runtime created by the Ionic Framework team. It natively runs modern Web apps on iOS, Android, Electron, and Web.

Advantages of Capacitor:

1. Compared with Cordova, it is a more modern framework and uses many new modern APIs.
2. It delivers first-class support for web apps and progressive web apps.
3. Native mobile developers can use Swift or Objective-C on iOS and Java or Kotlin on Android to build UI experiences or business logic and then expose them to the Web layer through Capacitor’s JavaScript-to-native APIs.

Disadvantages of Capacitor:

1. Builds can sometimes randomly crash without any reason.
2. Debugging can be challenging and time-consuming because of unclear error messages.
3. Some native plugins are not ready for production and can conflict with each other.
4. The performance is not as good as cross-platform frameworks or native apps.

Cordova is an open-source web-based mobile application development framework. It wraps your web app into a native container that can access several platforms’ device functions and Native APIs.

Advantages of Cordova:

1. It provides a faster time to market a product.
2. It is also perfect for testing a market.
3. The developer community is mature with lots of native plugins.

Disadvantages of Cordova:

1. The performance is not as good as cross-platform frameworks or native apps.
2. Third-party native plugins can have limited platform support or be outdated.
3. Native development expertise might be needed in some cases.
4. Cordova is volunteer-driven and does not prioritize the needs of any specific users.

Conclusion

In terms of business, there are no good or bad tools. Many factors like the following influence the choice:

• Time to market
• Application complexity and scalability
• The skill set of the development team
• Project budget

Hybrid and cross-platform frameworks promise lesser time to market. You save the development time initially, but in the later stages of development, it takes longer than expected when you have to inevitably write the native iOS and Android code and test the apps. Also, with declarative frameworks like SwiftUI and JetPack Compose, the app development time has been significantly reduced.

Long-term maintenance of cross-platform and hybrid apps is difficult as they depend on many third-party plugins and frameworks, which usually break with new OS releases. Support for the latest OS features usually takes a while to appear in the corresponding cross-platform components.

If your application has complex navigation or 3D animations, it isn’t easy to achieve these with cross-platform and hybrid frameworks. All cross-platform and hybrid frameworks have a performance overhead as they are computationally complex.

Regarding performance, hybrid apps are not very good as they run inside a WebView while communicating with the native APIs. In the case of React Native (cross-platform), it runs a separate JavaScript thread which diminishes the performance. The performance of Flutter is comparatively better, but it has animation jank. These performance issues are more evident when running the apps on lower-spec and old devices.

Those who advocate for a cross-platform or hybrid framework often say they can have a single codebase to target iOS and Android. However, a single codebase is not very practical in the long term, as there would be a lot of platform-specific checks scattered through the codebase. Also, sharing code among different platforms comes with some overheads. Dropbox did code sharing extensively and later dropped it as the overhead for sharing code eventually became more than maintaining two separate code bases.

Native applications provide a much better user experience and reliability and are easier to maintain and scale over time. If you are still working on an Objective-C codebase and are planning to migrate to Swift, you can save time rewriting the code by using Swiftify to focus more on the creative/intellectual work.

References:

• The (not so) hidden cost of sharing code between iOS and Android
• React Native: A retrospective from the mobile-engineering team at Udacity
• iOS jank — Reproducible example
• My Xamarin Journey: the Good, the Bad, and the Ugly
• Qt vs Flutter — 2020
• My Experience building an app for Android and iOS with Qt
• Not sure whether to develop hybrid or native app for my Medical startup

Top Mobile App Development Frameworks in 2024 was originally published in Swiftify on Medium, where people are continuing the conversation by highlighting and responding to this story.

Apple’s vision for Swift has been to perform efficiently and to be scalable. Swift 5.7 underwent significant changes to improve the language performance and quality of life improvements, like the if let shorthand syntax. So let’s dive deeper into the improvements and changes in the new Swift release.

Swift Package Manager improvements

Swift Package Manager now has a new security protocol, Trust on First Use (TOFU), where the fingerprint of a package is recorded on the first download, and subsequent downloads validate this fingerprint. Swift now allows multiple modules in a program to share the same name, thanks to module disambiguation.

Smaller and Faster Standard Library

The Swift standard library is now smaller and faster. Smaller, faster binaries are a huge benefit when running on event-driven server solutions.

Faster build and app launch times

Swift 5.7 has faster build times thanks to build parallelization and faster type checking of generics. Protocol checks are now cached, reducing the app launch times. In earlier versions of Swift, the protocols were computed every time the app launched.

Swift Language Usability

Shorthands for optional unwrapping

There are new shorthands for unwrapping optional variables without repeating the variable name for if let, guard, and while

Improved type inference for complex closures

Swift’s type inference for closures has improved. It is now able to infer the return type (String) of complex closures like this one:

Improved interoperability with C APIs

Swift, by design, is type and memory-safe, and never automatically converts between pointers of different types. This behavior contrasts with C, which allows specific pointer conversions. Earlier, this led to problems when using C APIs from Swift, so Swift now has a separate set of rules for calls to imported functions and methods. It allows pointer conversions that would be legal in C even though they usually aren’t in Swift.

Better string parsing with Swift Regex

A regular expression is a powerful tool for pattern matching and string manipulation. Regexes are very compact and sometimes difficult to understand and debug.

We now have three ways to create a regex. Let’s explore these by writing a regex to extract any words starting with # for the following string:

1) Creating a Regex from string

In earlier versions of Swift, we used NSRegularExpression like this:

In Swift 5.7 the syntax became much more concise:

2) Creating a Regex with Regex literal

The easiest way to create a regex would be using a regex literal, as shown below. The regex literal provides compile-time checks. You can learn more about regex literals here.

3) Creating a Regex using RegexBuilder

This provides an expressive result-builder-based, domain-specific language to build regular expressions, very similar to SwiftUI.

Unlock existentials for all protocols

Swift 5.7 significantly loosens the Swift’s ban on using protocols as types when they have associated type requirements. In simple terms, this means the following code becomes legal:

Conclusion

Swift 5.7 brings a lot of changes, quality of life improvements, and powerful new features like Swift regex, times and durations, distributed actors, and many others. It also paves the way for the way for full-thread safety, which would is planned to be released with Swift 6. The Swift team and collaborators are working on building interoperability with C++. Once implemented, we will be able to call C++ code directly from Swift.

References:

What’s new in Swift — WWDC22
What's new in Swift 5.7 - Hacking with Swift
What’s the difference between any and some in Swift 5.7?
Meet Swift Regex - WWDC22 - Videos - Apple Developer

You can contact us on Twitter, LinkedIn, Facebook and Github.

What’s new in Swift 5.7 was originally published in Swiftify on Medium, where people are continuing the conversation by highlighting and responding to this story.

We are excited to announce the final release of the Storyboard to SwiftUI converter, which now supports all major UIKit controls.

The converter now automatically groups SwiftUI views so that the compiler does not complain when dealing with complex view hierarchies.

At this point, we believe that the Storyboard to SwiftUI Converter can help convert a UIKit project to SwiftUI. For this demo, we took a Calculator project from the CS193p — Developing Apps for iOS Stanford University’s course, converted it to the latest Swift version, and then migrated it to SwiftUI. You can find the UIKit project here.

We would convert the storyboard into portrait orientation to get a fully functional SwiftUI project. If you want to follow along, please create a new SwiftUI project with Xcode 13+.

Note: We create a new SwiftUI project for this demo and import all code from the old storyboard project. For real-world projects, you may instead want to migrate the existing storyboard project to SwiftUI, as explained in this Stack Overflow post. This way, you can migrate your Storyboard views to SwiftUI incrementally rather than rebuild the whole project at once.

Convert Main.storyboard (portrait mode) to SwiftUI

To get started, convert the Main.storyboard file to SwiftUI using the Storyboard to SwiftUI Converter. Copy the converted SwiftUI code into ContentView.swift replacing all its contents and check the preview:

Refactor the converted code

Since ContentView.swift is a huge file, we can logically break it into different files:

1. Leave ContentView struct and ContentView_Previews struct in ContentView.swift
2. Move the extension to ContentView, which contains the button actions to ContentView+ButtonActions.swift
3. Move the DynamicSize struct and View extensions to DynamicSize.swift

Completing the button actions

Our converter currently handles only the Storyboard or XIB file but not the View Controller’s code. The converter generates the template code for the button actions located in ContentView+ButtonActions.swift.

We have to copy the appropriate code from ContentViewController into these action methods, adjusting it to use SwiftUI properties instead of UIKit.

• reset()

Copy the reset action code from ContentViewController.swift. The errors can be fixed by:

1. Adding brain and userInTheMiddleOfTyping state variables. Also, add CalculatorBrain.swift to the project.
2. Adding variables computed property, and since variables use a function inside String+BeautifyNumbers.swift, we add that as well.
3. Removing .text after variable as shown in the image below:

Similar functions like undo(), storeToMemory() and callMemory() can be refactored with the same approach.

• performOperation()

The performOperation action needs the sender’s title to operate in the UIKit project, so we change the action in SwiftUI to accept the title. Here is the refactored button action code:

We can build a function that constructs a Button with the title and calls the action to avoid code duplication. We can place this builder inside ContentView+ButtonBuilders.swift:

Now we replace the code that creates each operation button with the call to performOperationBuilder() function:

Also, touchDigit requires the sender’s title. We can add a builder function for this in ContentView+ButtonBuilders.swift.

Now we refactor the code that constructs each of the buttons to use the builder:

Now we can build and run the project with the full functionality present.

Final Thoughts and Upcoming Enhancements

We would ❤ to know your feedback about the converter. You can post your feedback or suggestions here.

The future version of the converter will add support for platforms like watchOS, tvOS, and macOS.

In the next release, we would support the remaining elements — UIActivityIndicator, UIProgressView, MKMapView, and WKWebView.

Update [April 2022]: We have added support for UIActivityIndicator, UIProgressView, MKMapView, WKWebView and segues.

Converting a Real-World Project from Storyboard to SwiftUI Using Swiftify was originally published in Swiftify on Medium, where people are continuing the conversation by highlighting and responding to this story.