Is it possible to write iOS app using Pure Swift v4.2 without going through Objective-C?

I would like to write a iOS app using pure Swift v4.2 using Xcode 10 and relying ONLY on Swift standard library and Cocoa APIs exposed as Swift APIs. Is this possible in year 2018 or we may need to wait few more years?

I read the latest Swift 4.2 reference book from Apple and understood most of the language. But realized after reading that in order to write iOS app using Cocoa API, one also need to understand how the Objective-C API works and it's runtime behavior as well than simply use the translated/bridged Swift API.

I feel like I wasted my time learning Swift by falling for the hype. I wish had spent the time learning Objective-C so I could have easily written the iOS app using just Objective-C.

I came across the book "Using Swift with Cocoa and Objective-C" from Apple and it is from 2014 . It told a very convoluted way of writing the swift iOS app to be able to interact with Cocoa API with all those annotations to facilitate Objective-C integration.

Is there any latest official documentation to integrate with Cocoa API using Just Swift? Not able to find one document that explains this than plethora of articles/videos.

Or Am I better off abandon swift at this time and learn and go with Objective -C only when building iOS app?

It seems Swift not ready for prime time in the context of writing pure iOS apps without some reliance on Objectve-C before year 2020 at least.

Please correct me if my above conclusions are incorrect.

Note : I have solid background in Java programming and related web back end. But due to a requirement, we are writing an iOS app using pure swift and was quickly disillusioned with swift. On hindsight, wish I had spent my time learning Objective-C than swift at this time. Not sure..

Sorry that you're disappointed, but luckily there seems to be some kind of misunderstanding. Yes, of course you can create iOS apps by only writing Swift code.

As a point of reference, Kickstarter have made their iOS app open-source and AFAIK it is written entirely in Swift (GitHub - kickstarter/ios-oss: Kickstarter for iOS. Bring new ideas to life, anywhere.). Apple also provide plenty of sample code, and when there are Swift versions they tend to be entirely Swift in my experience.

Can you be more specific about this? What lead you to believe that Objective-C was required? What parts of Objective-C do you feel you need to know?

1 Like

The Cocoa/CocoaTouch APIs are the same in Swift and Objective-C (subject to language-specifics, like naming methods, or differences in initializing, memory management). Understanding the concepts underlying the Apple frameworks is necessary to use those frameworks, regardless in a "pure" Swift, or Objective-C environment, and this philosophies are built upon the Objective-C runtime, which are also present in the Swift runtime. The complication with Swift you indicated when you referenced the Swift and C/Objective-C interface manual is needed only if you are writing/using C or Objective-C code within your application (Bridging headers, et al). However, for the Apple frameworks, there are native Swift APIs to use that access the frameworks, many of which are wrappers around Objective-C or C code.

One of the issues I've seen from folks who are trying to migrate from Java UI programming using Swing, AWT, et al , or Windows/C++, or Linux/Qt, or some web paradigm, is that the Apple frameworks fundamentally differ in important yet nuanced ways. The encouraged use of Interface Builder in building Apple applications also introduces some need for re-thinking your approach. Whether you use Swift or Objective-C, or a combination, you still need to understand the Apple framework concepts.

2 Likes

Thank you Jon and Karl,

Here is the thing. I agree that I need to understand the Apple frameworks when writing iOS apps.

My disappointment is around the fact Swift does not try to hide the Cocoa touch API's runtime behavior and complexity dictated by Objective-C. To be productive and write a reasonably useful iOS app with moderate complexity, I am finding out now that I also need to understand the Objective-C runtime behavior and it's quirks etc.

Few examples include : When Cocoa API forces me to pass via Swift exposed API (either bridged/overlays) those NS prefixed class objects ( for example NSRange vs Range). Now one need to understand how the passed objects will be interpreted by Objective-C runtime etc. and the returned NS prefixed Objects through the Swift exposed Cocoa API calls.

Swift does not seem to hide Cocoa API's Objective-C runtime behavior. May be I am pampered by how Java and Java SDK hide the complexity of underlying OS and various frameworks' runtime behavior and let me concentrate on solving the business problem implementation at hand .

Is there a latest v4.x official document from Apple ( preferably just one or two) on what the best practices are when writing Swift v4.2 based iOS apps and interacting with Cocoa touch APIs?

My thinking now is may be learning Objective-C would have been better time spent than Swift at this time in 2018. This may have let me understand the Objective-C runtime behavior and hence Cocoa touch API's behavior and my productive hours spent developing iOS app as per our business requirements.

It sounds like you're actually disappointed that Apple hasn't ported Cocoa(Touch) to Swift. Java is a self-contained environment. Anything made for that environment is going to be tailored to it. If you didn't have Swing, you'd have to bridge to Qt (for cross-platform support) and understand all the nuances of bridging to a C++ framework. There's no difference here. Apple doesn't (yet) have a Swift-native replacement for Cocoa, and likely never will. Cocoa is huge.

Honestly, you're making it seem much worse than it really is. You happened to find one of the few examples (Range vs NSRange) that is poorly handled, and you're projecting that on to the entire interop layer.

1 Like

Avi - You may have fair point. But here is the thing.

I am open minded and also want Swift to succeed. But not sure if year 2018 is appropriate or better waiting out few years.. when writing iOS apps.

There are many quirks associated with NS prefixed classes when one is hit with during Cocoa API calls etc. There are lot many examples I am finding out. (NSDate and NSData etc.)

Question : Do you see benefit using Swift for iOS apps vs. using Objective-C at this time, given one also need to understand the Objective-C runtime behavior due to Cocoa API implementation is based on Objective-C/C.

Sorry I am being critical, but so far the documentation I have read is leading me to come to the above conclusions.

@swf I will rehash this. Frankly, you don't even have to know what the objc runtime is to write a decent app in Swift. Relative to your concerns, all you might have to do is sometimes – in case you forgot – quickly look up the proper conversion for a problematic type pair (i.e. Range & NSRange). And even that isn't as cumbersome as you might have imagined; a lot of times it can easily be figured out via code completion. The need for mutual conversion for most relevant types will only start coming up when you engage large projects that cover a broad enough API surface, but will almost never be prevalent (if it still is, you can always write a helper function). I think the best answer is for you to actually give it a go.

1 Like

@anthonylatsis : Thanks!
I will sincerely try using Swift for 1 more week and hope all works out ok. If still having more obstacles and road bumps my best course of action may be to transition over to learning Objective-C to avoid all the troubles , bend over backwards with Swift.

Wish Apple had posted some sort of document to lay out the pros and cons of going with Swift when developing the iOS apps than letting Swift users figure out some of the above mentioned..

You haven’t really been very specific at all, so no one can make any recommendations to improve your experience. But Swift is a far better experience than Objective-C in nearly every way, even with the rougher parts of bridging.

3 Likes

I don't understand these examples. Both of those are bridged to Swift, as Date and Data, respectively.

I really don't know what aspects of Objective-C you think you need to know in order to write Swift apps for iOS. Again, your complaint seems to be entirely about Cocoa not being written in Swift. Outside of Java (and LISP machines), you're not going to find an environment where the "native" toolkit is a first-class citizen with respect to the available language.

I think you are missing two aspects with regards to the documentation:

  1. most of it was written before Swift, so will have an Objective-C bias.
  2. even today, there are those who are writing Objective-C, and need to understand how the frameworks work in that environment.

Neither point requires that you need to understand how they function in Objective-C.

1 Like

The last time I wrote any Objective-C was nearly 3 years ago, I've been writing apps (iOS and server side) exclusively in Swift since then. It used to be the case where bridging between the two languages had some rough spots, bit these days its pretty seamless. It's so seamless in fact that it would take me a few days to adjust to the nuances of Objective-C again just because I've simply forgotten them.

Yes you are using Swift to interface with an Objective-C API under the surface, but the bridging layer is pretty good at hiding away the Objective-C details and making them 'Swifty'. Are you sure it's not the API's themselves you are having a hard time with and not the language you are using to interface with them?

2 Likes

@swf keep in mind that most people here are very invested into Swift and most of them already have a lot of Objective-C experience. So keep that into context. Personally I would recommend to add a 0. prefix to Swift's version. So treat v4.2 as v0.4.2.

Swift cut a lot of corners in terms of standard library support and it basically outsourced most of it to Objective-C frameworks. That's why you are seeing all these weird behaviors. Contrast this with a language like Go where v1.0 had rich tooling and a standard library that included things like HTTP client/server support, cryptography and concurrency (all future plans for Swift).

My personal advice is to give Swift a try, it is a much nicer and productive language than Objective-C. But you will definitely need to learn a little bit of Objective-C to get by, there is no escaping that.

Can you elaborate? Yes, I was writing Objective-C for years before Swift was publicly-available, but I can't think of the last time I needed any of that knowledge to work in Swift.

NSObject, NSObjectProtocol, IBOutlet, IBAction, target-action, KVC, KVO, first responder, NSManagedObject, AnyObject magic, associated values... Those are all more or less easy to meet when you develop an iOS or a macOS apps, and they surely look foreign in Swift since they are all deeply rooted in the Objective-C runtime.

Take a MKMapView, for example. A basic need? Well, it uses KVO to move annotations on the map:

class MyAnnotation: NSObject, MKAnnotation {
    @objc dynamic var coordinate: CLLocationCoordinate2D
}

// Moves the annotation on the map, while preserving eventual selection.
annotation.coordinate = newCoordinate

Those @objc dynamic words are key to a good user experience.

And to understand how @objc dynamic can mean "KVO", you certainly need to know a great deal of Objective-C and Swift - assuming you already know that MKMapView uses KVO, and more or less what KVO provides.

I also mostly develop in Swift nowadays. But the knowledge of ObjC technologies have greatly help me, without any shadow of a doubt.

4 Likes

Good answers. I tend to think of those as Cocoa things more than Objective-C particulars. NS is for NextStep, after all, not for the language used. KVO is probably the killer ObjC-runtime feature that is commonly encountered. @IBAction and @IBOutlet are tags for Interface Builder, given a Swifty syntax. I don't see those as being Objective-C-isms in particular.

Overall, the OP has more complaints about the bridge to a non-Swift framework than he does about ObjC in particular. You can still get quite far with no ObjC knowledge.

1 Like

@gwendal.roue : Yes, These are some of the instances I am finding out. I could not have said any better.
By looking at apple video series , documentation etc. I thought it will be smooth ride to develop iOS apps by learning about Swift and Cocoa API. But I was wrong and I needed to know some of Objective-C internals , runtime behavior etc.

As @nick.keets pointed out, it seems Swift appears to have taken several shortcuts by outsourcing the work to Objective-C based frameworks and did not hide that complexity to Swift user. This is where my story began and was frustrated..

I can say given what I have read, To write pure Swift based iOS apps, one absolutely need to have reasonable knowledge of Objective-C internals , runtime behavior as a prerequisite.

It may be easy write a simple Swift based apps without knowing anything about Objective-C environment.
But that does not get you far enough and may not help with troubleshooting, writing moderately complex apps etc.

I have already started looking into Objective-C and trying to understand it's internals, runtime behavior and associated Cocoa touch framework behavior.

I will post my experience on this thread..

2 Likes

Excuse me for being blunt but, you are wrong.

I have used Swift ever since its launch and have written iOS and macOS apps in Swift without a single line of Objective-C code.

You might find some examples on the internet still written in Obj-C but Apple's docs are available in both Obj-C and Swift.

I will repeat - you do not need to know anything about the Obj-C "runtime"; what you do need is knowledge of the Cocoa Touch libraries, which were originally written in Obj-C but now have comprehensive Swift APIs

1 Like

Blockquote
will repeat - you do not need to know anything about the Obj-C "runtime"; what you do need is knowledge of the Cocoa Touch libraries, which were originally written in Obj-C but now have comprehensive Swift APIs

Sorry - That was not my finding. As I mentioned, I tried to concentrate only on using Swift and interacting with Cocoa touch API when tried looking into writing an iOS app based on our business requirement. The amount of tight coupling between Cocoa touch API and Objective-C runtime is huge and that was my finding. And Swift is not able to escape the Objective-C runtime behavior especially with all of those NS prefixed classes during my integration with Cocoa API. Now I have started already looking into understanding Objective-C runtime so I can understand why it feels to so strange to work with those NS prefixed classes and other frameworks based on Objective-C .

Keep in mind, before deciding to write the iOS app, I had no knowledge of Swift or Objective-C. I uncovered all the dependencies with Objective-C runtime behavior while going through the phase of understanding overall workflow and writing a moderately complex app.

Note: I am not new to programming and have solid background in Java and it's entire ecosystem. Have written as hobby some JVM languages using ANTLR. So I do know what I am talking about if you can pardon my language.

I am not blaming Swift here but the way it is designed when interacting with Cocoa touch API and forcing us to have knowledge of Objective-C runtime which feels like it was rushed through. My feeling is it may slow down language adoption with such dependencies. Hope Apple corrects the course in future Swift versions.

Please give an example. I think there’s some confusion over what you mean by “runtime”, as nothing mentioned so far really has anything to do with the actual Obj-C runtime.

2 Likes

Blockquote
Please give an example. I think there’s some confusion over what you mean by “runtime”, as nothing mentioned so far really has anything to do with the actual Obj-C runtime.

Sorry! I am using Obj-C runtime as umbrella term for : When we pass objects between Swift and Cocoa API through bridge/overlay etc. mechanism, hidden magic and annoyance with NS classes behavior, The memory management of these bridged objects without appropriate hints via the annotations that can be understood by Obj-C ( via compile time optimizations etc.), AnyObject generalizations etc.

Please see the post by @gwendal.roue in the above in this thread for some examples. selector mechanism and the resulting delegation, KVC and am finding more and more as I am going through this exercise.
The post by @rljames above seems to say some of what I have discovered too.