I need to insert native code in my Codename One app. I am a completely newbie in iOS programming so I need to learn Objective-C. However I read that Swift was the successor of Objective-C and I would feel more comfortable with Swift syntax. But I don't know if Swift is supported in Codename One. While looking at iOS source code generated by Codename One, although I am not 100% sure, it looks like C code (I may be wrong).
On his blog Shannah (from Codename One) wrote that
Codename One currently compiles everything down to plain old C code so we would be largely unaffected by such a change – although there would be some native portions that use Objective-C that would need updating. Luckily, if you’re a Codename One user, you don’t need to concern yourself with these details because you are working in Java.
I don't get it clear that's why I am asking whether it is possible to use Swift code in Codename One native code ?
Thanks a lot for helping me clarifying this topic!
Cheers
Yes and no. You can probably compile Swift code to a static library today (.a file) and just use that like any static lib where the Objective-C code just acts as a bridge.
Using Swift directly is problematic due to several factors:
Currently we are still using an older version of xcode when building, we made an attempt at migrating to the latest but had a setback. We'll migrate hopefully before 3.5 comes out, if not then shortly after.
Swift requires a relatively new version of xcode so until we do that embedding Swift code will be problematic.
Swift assumes ARC. This is something we tried to integrate with the GC but at this time it doesn't really work well.
We need to generate Swift stubs as an option, this is problematic as say you have existing cn1lib or native interface that relies on Objective-C it might create a conflict.
But lets back track a bit. Swift is a huge advantage over Objective-C which is pretty old by now. But it doesn't have any major advantages for Codename One developers...
It isn't faster as Codename One translates to C which is faster than both Swift and Objective-C
It won't make the code much cleaner, if you have a lot of code in your native interfaces then you are doing something wrong. Most of your code is in Java anyway, you can debate the merits of Java vs. Swift but if you are using Codename One then you pretty much picked Java.
If you need to use an app written in Swift you can package it as a static library.
So there is really no real use case for Swift in Codename One at this time.
Related
Actually, I am working on one app and started with the objective-c. Now i have started working on swift with the same app for the further development and it will work with both the class (objc and swift).
Now I have doubt that it will accept by apple store or not.
Please help me.
This is fine, Apple provides the mechanisms for interacting with both and will not drop support for Objective-C for quite sometime. Many large organisations still have the majority of their code written in Obj-C (including Apple) so they need to give people time to transition, they aren't going to switch over immediately to a relatively immature language.
You can use Swift and Objective-c together. There is no issue in it. You need to create a bridging header file.
Please read this
Swift and Objective-C in the Same Project
I am planning to learn to develop iOS apps. I'll most probably be learning Objective-C only for now and would like to develop some actual apps for iOS.
Now, with the launch of Swift 2.0, will Objective-C apps still run on iOS9 ? Also, is it possible to test run an Objective-C app on your phone like mentioned here ? https://developer.apple.com/xcode/
Or is this facility available only for apps written in Swift?
Does Swift allow me to do everything that Objective-C does?
Any further advide or guidance for what should I know before enrolling for the course will be appreciated to help me judge things better.
Swift is still just the second language. All Cocoa frameworks are written in C or Obj-C (maybe the new ones in iOS 9 are written in Swift).
The language in which an application is written doesn't matter, the code is compiled into the same machine code, so yes, Obj-C apps will continue to run and many developers won't bother with Swift. Apps that have been already written will not have to be rewritten to Swift (with some exceptions).
Swift won't allow you to do absolutely everything that Obj-C does but it will allow you to do almost everything and the code will be probably more robust, considering that Swift is more modern language with stronger typing than Obj-C. If you are a beginner, you won't probably find any problematic use case.
I have created an iOS mobile application. Is there a way to generate a UML class diagram for the Swift programming language?
I have tried Omni Graffle, but it keeps saying that the project doesn't contain Objective-C interfaces. And Omni Graffle only does this for Objective-C.
I remember looking at this question a while ago and was disappointed that there wasn't any tool like this so I created one myself with the help of a colleague. It's free, it's open source, it's looking for contributors...
https://github.com/yoshimkd/swift-auto-diagram
And here's a tutorial on how to use it (don't worry it's very simple):
https://martinmitrevski.com/2016/10/12/swift-class-diagrams-and-more/
Happy diagraming :)
The answer unfortunately is: you can't do it. At least not automatically. Swift as compiler itself has enough flaws left. Leave alone some tool will be able to swallow any Swift code. Your only alternative is the good old manual way.
I know that Enterprise Architect has a possibility to define a language syntax based on BNF. But Swift is (again unfortunately) not context free. (In fact it's so context sensitive that it often swallows its own rear.) So that won't work either.
P.S.: Now that Swift is open source someone might take the opportunity to tap the compiler's output for the class interfaces. I guess that should not be too difficult, but it's a lot of work still.
Inspired by swift-auto-diagram and similar open-source tools I started to work on such utility with the goal to write it in Swift (to make contribution easier by Swift developers) and to integrate it in Xcode and the Swift ecosystem.
Xcode extension: https://github.com/MarcoEidinger/SwiftPlantUML-Xcode-Extension
You are able to generate a class diagram from selected lines of code or from a whole file displayed in Xcode. The class diagram will then be opened in your browser. There you can modify the diagram with PlantUML notation
To generate a class diagram from multiple source files you can use the underlying CLI tool and Swift Package: https://github.com/MarcoEidinger/SwiftPlantUML
There is a size limitation to the visible diagram content (but you can delete content in the browser with PlantUML notation)
The first thing I tried is to create a static library but later I found out that it's not supported yet. Apple Xcode Beta 4 Release Notes:
Xcode does not support building static libraries that include Swift
code. (17181019)
I was hoping that Apple will be able to add this in the next Beta release or the GA version but I read the following on their blog:
While your app’s runtime
compatibility is ensured, the Swift language itself will continue to
evolve, and the binary interface will also change. To be safe, all
components of your app should be built with the same version of Xcode
and the Swift compiler to ensure that they work together.
This means that frameworks need to be managed carefully. For instance,
if your project uses frameworks to share code with an embedded
extension, you will want to build the frameworks, app, and extensions
together. It would be dangerous to rely upon binary frameworks that
use Swift — especially from third parties. As Swift changes, those
frameworks will be incompatible with the rest of your app. When the
binary interface stabilizes in a year or two, the Swift runtime will
become part of the host OS and this limitation will no longer exist.
The news is really alarming for me a person who writes components for other developers to use and include in their apps. Is this means that I have to distribute the source code or wait for two years?. Is there any other way to distribute the library without exposing the code (company policy)?
Update:
Is Swift code obfuscation an option at this point ?
Swift is beta now, and even for 1.0 Apple has been pretty clear they're after a restricted feature set -- better to do a small number of things well than to try to do everything.
So for now, there's no way to distribute binary static libraries. Presumably that'll change sometime after Swift 1.0. For now, you can:
Distribute source
Ship a binary framework (instead of a library) if you're okay with the ABI being fragile
Use ObjC for library code
You can always combine approaches, too: e.g., implement the critical (secret) details of your library in ObjC, and ship Swift source that wraps it in a nice Swift API.
Obfuscating code written in a language that's very much subject to change sounds like a recipe for a maintenance nightmare.
I believe the whole approach is wrong. You cannot do something that is not (yet) doable by the technology you are trying to use.
Rationale: Swift is a new language, currently in Beta, and therefore changing. As I see it, this fact means not only that you are not able to ship static libraries, but that (real) developers will not be actually use third-party static libraries. What's the actual use of a library that may not work in the next release of the compiler? The issue gets bigger if you whant to use more than one library, because they might not be compatible! Therefore, even if you would be able to ship static libraries, they wouldn't be actually useful for production environment. So, what's the point?
Suggestion: write your static libraries in Objective-C (or C or whatever "non-beta"). Developers who need third-party libraries (e.g. yours) shouldn't expect them to be written in Swift until Swift is stable. You don't use experimental materials to build real bridges, right? You use well-tested, predictable ones.
From Xcode 9 beta 4, Xcode supports static library with Swift sources.
Hi, I'm just wondering how you could obfuscate functions in iOS binary?
If you tried to reverse iOS binaries using tools like ida you will see part of the binaries have obfuscated functions like all or partly named sub_xxxxxxxx but the other have human readable functions
Someone said, add those lines to the top of your header without any further explaining:
#define SecurityClass ah7p
#define checkCopyProtection xcyc
What the methods used to secure your App?
Sorry for the dumb question, but I'm new there and I ended up with no answer explained what I need.
There are a couple of ways to obfuscate an iOS binary.
Open Source compiler named llvm-obfuscate (https://github.com/obfuscator-llvm/obfuscator/wiki) It has some nice features to obfuscate during compilation. You are replacing your default compiler with that one.
There are for Windows of course VMWare oder Themdia that can post process but that is not the case.
Besides that I just know one more which is Liasoft antispy. It is a very advanced anti analysis toolkit that allows you to encrypt functions and much more during compilation using mixed Objective-C and C++ code. ( https://www.liasoft.de/en/products/antispy/ )
Not sure if one of these is the right one for you. Except these things you are pretty lost since Objective-C is a compiled language with lots of metadata.
Hope I could help you, this is my first post.
If you only care about obfuscating method names then the easiest way is to write relevant parts of your application in C or C++. For instance, you can rewrite your SecurityClass as a C++ class instead of Objective-C class. This will not make your code reverse-engineering-proof, but it will at least raise the bar a bit. (NOTE: I'm not saying this is the right thing to do from software engineering point of view, though).
If you need to obfuscate code, then you are in a search for a tool that can do this. There are several such tools, both commercial and free. One project for doing exactly this is obfuscator-llvm.