Make ejected iOS app a Swift app, not Objective-C

[DaKaZ]

Introduction

Hello, I have developing in ReactNative for over two years and have contributed to the core as well, I've seen the process and can only say THANK YOU to all who make this wonderful platform possible - its more then a full time job.

The purpose of this issue is to discuss the possibility of converting the core iOS app from Objective-C to Swift. I am not a native iOS developer nor do I have a lot of experience with ObjC nor Swift, but it seems to me that Swift can do everything ObjC can do and more, but ObjC cannot do what Swift can.

The Core of It

In my day job - I write cross platform apps for the government in ReactNative. We use AirWatch as an MDM have integrated the AirWatch SDK into our apps to provide security and management. Earlier in 2018, AirWatch stopped releasing ObjC code and only released their SDK in Swift. Since the SDK requires that we subclass AppDelegate from the Swift based AWControllerDelegate, I had to transform our app's main AppDelegate from ObjC to swift. ObjC does not support subclassing from swift (https://stackoverflow.com/questions/35244592/inherit-from-a-swift-class-in-objective-c)

Discussion points

I think there are several key discussion points we need to consider:

• Are there any compelling reasons NOT to covert a RN ObjC iOS core app to swift?
• How is linking and 3rd party modules affected by this change
• Do we change the core react-native eject to output a swift app OR do we write scripts to convert the outputted app to swift?

Once we've discussed this, I am happy to put together an initial PR that does the conversion and marshal through the code review / PR process, but I don't want to do this without a clear understanding of what the core team would find acceptable and advisable as this has the probability of being a large PR.

Reference

For reference, here is the AppDelegate.swift file that implements the AirWatch SDK in a minimal way (Note: this is only a minimal representation, in our real implementation I have a native-module bridge which provides information to/from the RN app and these stubbed functions):

//
//  AppDelegate.swift
//
//  Created by Kazmier, Michael S (CTR) <***email_removed***> on 10/15/18.
//  Copyright © 2018 USCIS. All rights reserved.
//
// Derived from https://stackoverflow.com/questions/40081012/react-native-app-purely-in-swift

import UIKit
import AWSDK

@UIApplicationMain
class AppDelegate: UIResponder, UIApplicationDelegate, AWControllerDelegate {
  var window: UIWindow?
  var bridge: RCTBridge!

  func application(_ application: UIApplication, didFinishLaunchingWithOptions launchOptions: [UIApplicationLaunchOptionsKey: Any]?) -> Bool {

    /**
     * Loading JavaScript code - uncomment the one you want.
     *
     * OPTION 1
     * Load from development server. Start the server from the repository root:
     *
     * $ yarn ios
     *
     */

    let jsCodeLocation = RCTBundleURLProvider.sharedSettings().jsBundleURL(forBundleRoot: "index", fallbackResource: nil)


    /**
     * OPTION 2
     * Load from pre-bundled file on disk. The static bundle is automatically
     * generated by "Bundle React Native code and images" build step.
     */

    // let jsCodeLocation = NSBundle.mainBundle().URLForResource("main", withExtension: "jsbundle")

    let rootView = RCTRootView(bundleURL:jsCodeLocation as URL?, moduleName: "**AppNameRemoved**", initialProperties: nil, launchOptions:launchOptions)

    self.bridge = rootView?.bridge

    self.window = UIWindow(frame: UIScreen.main.bounds)
    let rootViewController = UIViewController()

    rootViewController.view = rootView

    self.window!.rootViewController = rootViewController;
    self.window!.makeKeyAndVisible()

    // Initialize AirWatch
    let awcontroller = AWController.clientInstance()
    awcontroller.callbackScheme = "**AppUrlRemoved**"
    awcontroller.delegate = self
    awcontroller.start()

    return true
  }

  func application(_ application: UIApplication, open url: URL, options: [UIApplicationOpenURLOptionsKey : Any] = [:]) -> Bool {
    // `AWController.handleOpenURL` method will reconnect the SDK back to its previous state to continue.
    // If you are handling application specific URL schemes. Please make sure that the URL is not intended for SDK Controller.
    // An example way to perform this.
    let sourceApplication: String? = (options[UIApplicationOpenURLOptionsKey.sourceApplication] as! String)
    let handedBySDKController = AWController.clientInstance().handleOpenURL(url, fromApplication: sourceApplication)
    if handedBySDKController {
      AWLogInfo("Handed over open URL to AWController")
      // SDK Controller will continue with the result from Open URL.
      return true
    }
    // Handle if this URL is for the Application.
    return false
  }

  func controllerDidFinishInitialCheck(error: NSError?) {
    if error != nil {
      AWLogError("Initial Check Done Error: \(error)")
      return
    }
    AWLogInfo("SDK Initial Check Done!")
  }

  func controllerDidReceive(profiles: [Profile]) {
    // This method to designed to provide a profile for application immediately after the controller has received
    //
    //
    // Usually, Applications receive SDK Settings as Profile.
    // Application will receive a profile updated by admin according to the following rules.
    //  1. When App is being launched for the first time.
    //  2. When Application is being killed and relaunched (cold-boot).
    //  3. After launched from the background and last profiles updated more than 4 hours ago.
    //
    // In other cases, the cached profile will be returned through this method.
    //
    // Note: First time install and launch of the application requires a profile to be available.
    // Otherwise SDK Controller Start process will be halted and will be reported as an error.
    // Generally, this method will be called after `controllerDidFinishInitialCheck(error:)` except in
    // the instance of first time launch of the application.
    //
    AWLogVerbose("SDK received \(profiles.count) profiles.")
    
    guard profiles.count > 0 else {
      AWLogError("No profile received")
      return
    }
    
    AWLogInfo("Now printing profiles received: \n")
    profiles.forEach { AWLogInfo("\(String(describing: $0))") }
  }

  func controllerDidReceive(enrollmentStatus: AWSDK.EnrollmentStatus) {
    // This optional method will be called when enrollment status si retrieved from console.
    // You will receive one of the following.
    //      When Device was never enrolled:
    //        `deviceNotFound`:
    //
    //      When device is in process of enrollment:
    //        'discovered'
    //        'registered'
    //        'enrollmentInProgress'
    //
    //      When device is enrolled and compliant:
    //        'enrolled'
    //
    //      When device is unenrolled or detected as non-compliant:
    //        `enterpriseWipePending`
    //        `deviceWipePending`
    //        `retired`
    //        `unenrolled`
    //      When network is not reachable or server sends a status that can not be parsed to one of the above.
    //         `unknown`
    AWLogInfo("Current Enrollment Status: \(String(describing: enrollmentStatus))")
  }
  
  func controllerDidWipeCurrentUserData() {
    // Please check for this method to handle cases when this device was unenrolled, or user tried to unlock with more than allowed attempts,
    // or other cases of compromised device detection etc. You may recieve this callback at anytime during the app run.
    AWLogError("Application should wipe all secure data")
  }
  
  func controllerDidLockDataAccess() {
    // This optional method will give opportunity to prepare for showing lock screen and thus saving any sensitive data
    // before showing lock screen. This method requires your admin to set up authentication type as either passcode or
    // username/password.
    AWLogInfo("Controller did lock data access.")
  }
  
  func controllerWillPromptForPasscode() {
    // This optional method will be called right before showing unlock screen. It is intended to take care of any UI related changes
    // before SDK Controller will present its screens. This method requires your admin to set up authentication type as either passcode or
    // username/password.
    AWLogInfo("Controller did lock data access.")
  }
  
  func controllerDidUnlockDataAccess() {
    // This method will be called once user enters right passcode or username/password on lock screen.
    // This method requires your admin to set up authentication type as either passcode or
    // username/password.
    AWLogInfo("User successfully unlocked")
  }
  
  func applicationShouldStopNetworkActivity(reason: AWSDK.NetworkActivityStatus) {
    // This method gets called when your admin restricts offline access but detected that the network is offline.
    // This method will also be called when admin whitelists specific SSIDs that this device should be connected while using this
    // application and user is connected to different/non-whitelisted WiFi network.
    //
    // Application should look this callback and stop making any network calls until recovered. Look for `applicationCanResumeNetworkActivity`.
    AWLogError("SDK Detected that device violated network access policy set by the admin. reason: \(String(describing: reason))")
  }
  
  func applicationCanResumeNetworkActivity() {
    // This method will be called when device recovered from restrictions set by admin regarding network access.
    AWLogInfo("Application can resume network activity.")
  }
}

[shergin]

First of all, I am a huge fan of Swift.

Swift can do everything ObjC can do and more, but ObjC cannot do what Swift can

I am afraid, the reality is totally opposite.

the SDK requires that we subclass AppDelegate from the Swift based AWControllerDelegate

🙄 Someone should tell them that's just wrong. What if I want to use two SDKs with same requirement?

[axemclion]

I am not sure if there is any actionable work item from this. I am afraid that we may not be able to support this, and I am not aware of any plans to do this in the near future.

Does it make sense to close this issue, and maybe re-open it is someone is interested in picking this up ?

cc @hramos

[kelset]

(Personally I believe we can leave this open since the conversation of ‘moving to Swift’ comes up from time to time)

[DaKaZ]

@shergin thanks for the feedback. I really wish I knew the native code better! FWIW: I have passed the feedback along to cisco/vmware and hopefully they will re-release their ObjC based SDK.

[rhdeck]

FWIW I have had great success both linking Swift libraries with RN and authoring new libraries in Swift. I don't think this requires changing the core code, and I've contributed tooling that might be relevant for @DaKaZ :

• react-native-swift to enable Swift-based SLs in RN
• react-native-swift-base to replace the stock AppDelegate.m with AppDelegate.swift to make extending easier
• react-native-swift-bridge to auto-generate the bridging m, h and js code from writing a Swift module
• react-native-swift-cli to demonstrate how to build swift-based native components for RN

[DaKaZ]

@rhdeck wow - I wish I had found these and/or used them months ago - I slogged through converting my app to swift on my own and your react-native-swift-base would have done the job for me!

I am curious about your thoughts for my implementation. As I said before, we are integrating the AirWatch SDK and it has a requirement to subclass it's delegate from the AppDelegate class. Am I right in thinking that the ONLY way I can support this is to first convert the AppDelegate to swift and then subclass it or is there another way that would work? I only ask because you clearly have a ton of experience here. Thanks!

[rhdeck]

Hit me with an issue on one of my repos (like RNSBase) so we don’t pollute this more general purpose forum.

…

On Tue, Jan 15, 2019 at 5:12 PM DaKaZ ***@***.***> wrote: @rhdeck <https://github.com/rhdeck> wow - I wish I had found these and/or used them months ago - I slogged through converting my app to swift on my own and your react-native-swift-base would have done the job for me! I am curious about your thoughts for my implementation. As I said before, we are integrating the AirWatch SDK and it has a requirement to subclass it's delegate from the AppDelegate class. Am I right in thinking that the ONLY way I can support this is to first convert the AppDelegate to swift and then subclass it or is there another way that would work? I only ask because you clearly have a ton of experience here. Thanks! — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#82 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ALov_2Lh6rylB5bTz7tSrjSnySiizeEyks5vDlI5gaJpZM4Z3xw-> .

[eliperkins]

What do folks think about at least allowing for an option to have the app delegate in Swift, as well as flipping the correct Xcode toggles to enable adding more Swift code in the future?

As someone who has written a bunch of Swift and developed out a Swift-ish React Native app over the last two years, I believe this is something I could put a PR up for if folks were interested in it. The app delegate for a React Native app is fairly trivial (initializing the bridge, creating an RCTRootView, and slapping that root view onto a view controller, then the window). This could be accomplished with a second template, and an option in the react-native-cli to handle which template to install.

The trickier part will be creating a bridging header and setting that in the xcodeproj, as well as setting the correct Swift config flags.

This would be made a lot easier if we didn't use a hardcoded xcodeproj as the base and instead generated it on the fly using something like Buck/Bazel, tuist/xcodeproj or other tools to generate new Xcode projects from a set of inputs. There was some discussion around this in #15, specifically this comment from @shergin: #15 (comment)

What I don't think we should tackle as part of this discussion is enabling Swift-containing static libraries (while this should be easier with a Swift app delegate), or Swift-based view managers, etc. The resources @rhdeck linked to definitely help out with those things!

[eliperkins]

Related prior art: How create-react-app allows for other languages like Typescript

[DaKaZ]

@eliperkins I was just recently introduced to @rhdeck 's react-native-swift-base which does exactly what you are proposing. If you add this package (and its peer deps) when you run react-native link it will migrate your app delegate to be swift. I am only a day into playing with it, but it seems to be working quite well for me. I think there are some improvements we can make such as publishing his react-native-swift-registry to make installation a little cleaner, but I don't think adding swift support into the core RN code is worthwhile when we can do it outside of project. Having gone through the process of changing the core (I had the PR which allows you set the packager port to something other then 8081) its not an easy thing to do and since the ObjC base provides more functionality, I don't see why the maintainers would want to adopt more code to maintain. Just my $0.02 worth. I would personally like to see the effort go into maturing react-native-swift-base

[eliperkins]

I was just recently introduced to @rhdeck's react-native-swift-base which does exactly what you are proposing

Oh neat! Sounds like a prime use-case for a react-native-cli plugin then, rather than relying on the side-effects of rnpm prelink. Maybe a better use of my time could be to convert/extract @rhdeck's work on react-native-swift-base into a react-native-cli plugin, akin to how @grabbou did with the app-registry-components-to-constants plugin

[michalchudziak]

I think it's not a matter of what's better Obj-C or Swift. I find Swift nicer to work with, and definitely, I'd like generated app to be written with that, since it could save me some time rewriting AppDelegate. But there are cases where you'd probably want to stick with Objective-C and I believe what we need is to have an ability to choose on init.

I already placed my thoughts on that here: react-native-community/cli#91 (comment)

[yvbeek]

The use cases for writing new code in Objective-C instead of Swift are slim to none nowadays. It could be a good boost for React-Native to be a bit more Swift / Kotlin minded. Swift now has a stable ABI and it is clear from this year’s WWDC that Objective-C is fading into the background.

People that start off with a new React-Native project are dropped into Objective-C code. Not a great experience, that might scare off novice developers.

Swift Packages support is another thing to consider.

@rhdeck Thank you for that list of repositories!