I have an old library in objective C, developped by several people following (one stop and the next continue the project...).
This library is used in several applications, most of them developped in objective C.
I want to add new features in this app, but the code is not maintainable actually (no tests, no comment, etc...).
My main idea was to rebuild a framework or library in Swift. I have the business requirement but I'm not comfortable with objective c.
Am I going to have compatibility problems if I want to use my new swift library in "old" objective C application, or It could be great If I don't change the API?
Could it be transparent for the client who have his own application and have to use the new library now?
As long as you keep the interface the same and mark all previously public methods/properties as #objc, there should be no breaking changes to the API of the library and hence all consumers should be able to continue using it without any changes on their side.
However, be aware that having to mark all methods as #objc will limit your ability to use the full extent of Swift, since some features of Swift are not available in Obj-C and hence if you want your types/functions to be available in Obj-C, you cannot use such features (i.e. you cannot use tuples in function signatures or add methods to your enums).
Related
I'm relatively new to Swift (I've tinkered with Python and HTML in the past)- but I'm currently working on an app with a group.
This app already exists as a desktop program written in Ada and we were hoping to port it over to Swift and put out an iPhone app.
My understanding is that I can (likely?) turn the Ada into C with a converter, then reference the C in Swift? Is this correct, or have I overlooked something due to not being familiar with the languages?
If correct, how would I go about actually executing this since I have little experience in Swift and C?
This is a pretty loaded question, so thank you for any help or insight!
edit: said desktop application is open source and available for all use- I do not intend on stealing anyone's work
I'm assuming that you can easily pull out the parts of the Ada program that you want to use in the iPhone program. If the code that you want to port over has other dependencies, then you have to make sure that you can get all of these dependencies for iOS as well. This may be extremely difficult for UI toolkits, if you use one.
To call foreign functions in Swift, you usually need to use a bridging header. Your target's bridging header contains C and Objective-C declarations of classes, functions and variables that Swift should be able to call into. As long as the language that you want to call into can export C-compatible bindings (which should be the case of Ada), then you will be able to call these bindings by declaring them in your bridging header.
If the part of the desktop Ada program that you want to use can easily be isolated in a library (static or dynamic), and you are capable of building that library as an ARM Mach-O library, then it's simply a matter of declaring the functions that you want to use from the library in your app's bridging header. You can refer to GNAT User's Guide for Native Platforms: Interfacing to C for the directives to use to expose an Ada function to C, and by exposing it to C, you're also exposing it to Swift. I'd try this first, as maintaining the almost-unmodified Ada source is almost certainly going to be easier than maintaining a mechanically-translated C version of the Ada source.
If that doesn't work, then yes, translating the Ada source to C code will also allow you to reference it from Swift. You will also have to ensure that the functions that you need to call are declared in your bridging header.
It looks like it used to be possible to compile Ada in Xcode when Xcode still supported the GCC compiler. That was removed a while ago.
If there are translators that will translate Ada to C then you could use C natively in an Objective-C iOS app. (Objective-C is a pure superset of C, meaning that all C code is also legal objective-C.)
Swift "plays nice" with C and Objective-C as long as you limit yourself to the types and classes that C and Objective-C understand, but inter-operating between Swift and C/Objective-C is somewhat tricky and tedious. You would have a fair amount of reading and study to do in order to learn how to build an app that uses both, on top of everything else you would need to learn.
Unless you're dealing with many thousands of lines of Ada code it might be better to find somebody who knows both Ada and Swift to translate the code for you, or for you to learn Swift and then translate it yourself.
Unfortunately, There is, at this time, no Ada compiler which targets iOS available to the public.
If you have cash to spend you could contact AdaCore for one, don’t expect it to be cheap though.
Believe me, there are some of us who would like to target iOS with Ada.
I am only aware of two Ada to C compilers, the most powerful one (AdaMagic) is now known as MapuSoft Ada-to-C/C++ changer. You'll need either Windows or Linux execution environment to run translator (Wine, Docker, etc. on macOS). Also, you'll need to limit yourself to Ada 95. AdaMagic is said to support a "subset of Ada 2005", but I am yet to stumble upon this subset. Also you'll need to port the runtime or a part of it. If you disable runtime checks, the amount of runtime required to port becomes lower, so it is up to you how much time you are willing to spend on it.
It has two modes of operation, either targeting C, or C++, I recommend C++ because throw-catch is a better match with modern Objective-C runtime (utilizing C++ ABI behind the scenes) than C setjmp/longjmp.
With some effort you'll get something up and running.
It is a pity Ada developers are so unaware of this option. Maybe somebody could find time to port AdaMagic to EmScripten, iOS, Elbrus or whatever essential target the humanity is missing to start mass Ada adoption.
Others advised producing Swift bindings from bridging headers, but IMO the winning strategy would be to write glue code in Objective-C++ hybrid. Objective-C++ will have access to both Swift code (viewed as external Objective-C classes) and Ada-to-C++ translated code. For instance, it will be able to catch C++ exceptions from Ada and throw Objective-C ones or vice versa.
Another compiler is GNAT CCG aka SPARK2C. It is designed to target embedded devices having no other Ada compiler. It supports recent Ada standards, but is very limited with regards to features requiring runtime. Basicly, there is no runtime. No runtime, no problem. Nothing to port. In this compiler one can return limited record from function (Ada 2005+ feature), but cannot have RAII, tasking, etc. I guess, that are far more strict requirements than Ada 95. GNAT CCG is not yet publicly available, but I expect it to appear before annual Make with Ada, otherwise that would be a very stupid situation.
Another options are Ada-to-Java or Ada-to-.NET, maybe they can work for your application better than others.
I need to present and open pdf documents in my app. I would like to avoid third part libraries, because of update reasons (and I couldn´t find anyone created in swift).
I have been looking at QLPreviewController, UIDocumentInteractionController and presenting the pdf in an UIWebView. All these alternatives works fine for just presenting the pdf but I can´t find any built in search. I want functionality like the iBooks app.
Any advice is appreciated!
You'll likely wont find any 3rd-party frameworks written in Swift yet, simply because as of Swift 2.2 it's not binary compatible yet, and any binary framework written in Swift would be very fragile to break with even a minor update of Xcode (and updates to the compiler, that is).
I'm working on the commercial available PSPDFKit SDK for both iOS and Android. We're actually using a lot of C++ internally since raw performance is very important and Objective-C (and for many things, also Swift) are not yet fast enough for certain tasks.
We did invest a lot of time in adopting the latest Objective-C features such as nullability and generics next to declarations such as noescape for block-based API to make our SDK great to consume from within Swift.
While a separate Swift-wrapper could offer additional convenience, you'll find it very simple to use, and we're always working to adopt more features that improve bridging as they come available - there are a few interesting things in the Swift 3 proposals.
If you do not want to go the framework route, you can use CGPDFScanner to base a custom text extraction engine on. You will need to read up on Character Map Parsing - Page 446ff and many other sections - extracting text from a PDF document is surprisingly difficult, and after much work you'll be left with individual glyph positions and need to approximate where words are and if the document uses spaces or if you need to synthesize your own to correctly extract text. It's something that just takes a lot of experimentation and approximation to get right.
I'm trying to translate an Objective-C app into Swift and I don't know how to implement a malloc.
Is it possible to use it in Swift?
Thank you
You need to implement a bridging header when you use ObjC or C from Swift. The functions exported by your bridging header are then available in your Swift app/module. See here, for the overview.
If you just need to "call some code" on the C-side, then the functions exported from C are basically just wrappers for Swift. However, if you need to interact with the data returned from those functions -- especially if malloc'd and not a simple primitive -- Swift has a number of C related types ready for your use (see here for specifics).
Furthermore, if you're trying to wrap or interact with C++ code, you can't directly do so from Swift. You have to setup an initial interface with ObjC or C for the C++ code, and then bridge that to Swift. Not really fun at all, but thankfully it's not as common a use case as bridging ObjC (primarily) or C.
... and for what it's worth, unless you need low level Core Audio for some reason (granted, like porting an app you already have), AVAudioEngine (iOS8+) is so much simpler for any applicable use case than Core Audio, and is readily available in Swift.
Do I need to learn and convert my entire codebase to the new Swift language if I want to support ios 8?
No. The APIs available from Swift are exactly the same as the APIs available from Objective-C; you can code against any iOS 8 APIs from either language.
To start writing in Swift, there's an option called Migration. It will convert your existing code into swift code
Migration provides an opportunity to revisit an existing Objective-C
app and improve its architecture, logic, and performance by replacing
pieces of it in Swift. For a straightforward, incremental migration of
an app, you’ll be using the tools learned earlier—mix and match plus
interoperability. Mix-and-match functionality makes it easy to choose
which features and functionality to implement in Swift, and which to
leave in Objective-C.
NO.
Your Swift code can be run alongside your Objective-C code because Swift is built with the same compiler, ARC management and runtime as Objective-C.
I am a developer working on a robotics application for iOS. I do not intend to submit this app to the app store, nor do I have any wish for suggested methods to be apple approved....
I am trying to get bluetooth working, and I think a good place to start is to try modifying the existing apple frameworks. Is it possible for me to modify the frameworks so that when they are built to my iOS device the frameworks will be modified for the app (but not other apps on the same device)?
As a matter of fact, you can!
Objective-C allows you to "swizzle" methods to override their default behavior, and yet still call the original implementation if you want to. You can do this for any number of Objective-C methods, as many times as you want.
If you wish to override behavior that is present in C functions, you will need a little bit more control over the platform. Jailbreaking allows you to use the full power of Jay Freeman's CydiaSubstrate to hook or swizzle both Objective-C methods and C/C++ functions.
While I don't recommend the use of MethodSwizzle per se, the following URL has a good discussion of swizzling http://cocoadev.com/wiki/MethodSwizzling.
But you should really use CydiaSubstrate's MSHookMessageEx and MSHookFunction instead. Especially since you're not submitting anything to the App Store.
Now regarding Bluetooth, I've done extensive work in this field (I developed Celeste, which is a systemwide tweak providing vanilla Bluetooth OBEX support to system apps on iOS). I suggest you look into using something like BTstack, which provides you with access to the bluetooth module from the HCI to RFCOMM levels, and supports things such as SDP and pairing, which you will probably need. It also has the added benefit of not requiring method swizzling, which some people seem to think is some sort of satanic ritual that should be avoided at all costs.
Aside from categories (which extend the functionality of base classes delivered in those frameworks), I don't believe you can "modify" the existing Apple frameworks per se. A better course of action might be to simply create your own framework (or find somebody else's open source, commercial or simply third party framework) and then build that framework into the app that you install onto the iOS devices you want to work with.