I've been running a Xcode project on my iPhone but I haven't upload the binary yet. The thing is that I've lost the code on my Mac (that's what happens when you don't commit con GitHub) and the only thing I still have from the project code is the "app" that the iPhone saved when I run it for the first time. Is there any way to pass the code from the iPhone or see the code?
No. Your code was compiled, linked and packaged to produce the application, and it is the resulting compiled binary that has been installed on your phone.
You may be able to retrieve resources (storyboards, XIBs, images, plists...). For the code, there may be decompilers (not sure if there are any for Objective-C or Swift, though), but they will not reproduce your original code, just code that compiles to the same thing (i.e. without comments, with arbitrary names for local and instance variables, etc.).
Don't you have a Time Machine backup of your project?
Related
I have a Xcode project I got from another developer. Initially when I opened it it has a bunch of errors (most of which were un-updated frameworks). I got it to work after a while and I fixed it. I want pass it back to the manager since I'm leaving uni in a few months. I copied it over to my friends Mac to see what would happen if I just took the project and all it's folders and made it a zipfile. It didn't work for some reason. It gave me an error:
error: using bridging headers with framework targets is unsupported
But why did that come up? I mean it's the same code on the slightly different versions of Xcode (13.1 versos 14.1) but I doubt there was a massive change between the two that would cause this. I want to be able to pass these app later in the future without having to care about this stuff. I made a GitHub (link below) would cloning that work? Also the laptop I chose was just a fresh reset. Would it be due to not having coco-pods installed?
I feel like I could go through and fix it all on that laptop and document that but then I'm afraid that every time I put it on a new one it would come up with random errors every single time making my documentation moot.
https://github.com/AbdullahMSaid/SonicExperiment-Works
With big help this was Fixed.
Things that fixed it.
Having the correct version of Xcode
Turning everything from absolute path to relative
Lots of other code fixes. But those are my project specific.
You don't need bridging headers in framework. Use should have something like "YourFramework.h" where you can import your .h files.
I want to see the code of an iOS app.
The app I downloaded is .deb.
First question: Is it possible to install .deb file on iOS or I downloaded a wrong file?
After unpacking the .deb file, I got some files, including .nib, .storyboard and some other files.
My main question is, How to decompile these .nib files?
I tried to decompile these files using NibToXibConverter, but I didn't succeed.
Answer to your first question:
I think you downloaded the wrong file. .deb files for iOS are common for jailbreak community and not for apps, I think all of the Cydia stuffs are packed into .deb's. If your app is especially made for the jailbreak scene then you may try to install it using Cydia's auto install feature on a jailbroken device.
Answer to your main question:
This is general info about decompiling and modifying iOS apps (not specific for nibs, but you may still find it useful).
iOS apps are distibuted in .ipa archives, which are ordinary zip archives. They contain, usually one executable in the form of Mach-O file, and resources like .plist, sounds, images - every resource you include in your xcode project. Decompiling the executable file is only possible on jailbroken iDevice, because it is encrypted especially for the current device and the magic key to decrypt the binary is burned inside the device CPU and as far as I know there is no software way to read that key. The encryption system here is called FairPlay.
Briefly described, one way to decrypt that binary is to have the app installed on a jailbroken device, and launch it from command line using a debugger (gdb) which you can download from Cydia. You have to set a breakpoint somewhere, and when your code execution pauses at the breakpoint, you are doing a memory dump of the device ram - and that is your decrypted bin.
So when you have the decrypted binary, you can run one tool called "class-dump", and get the information for declared classes and their methods if the app is written in Objective C. Once you know this information you can alter the implementation of given method from some class used in your app using "Cydia Subtstrate" a.k.a "Mobile Substrate". In fact that is the way all of the jailbroken iOS tweaks are made. Basically you are hooking a method call, and when that method get invoked, it uses your implementation. Furthermore your implementation can call the original implementation, and that is really useful if you want to make some small code addition.
I am not sure whether those things possible in Swift, but if you are dealing with a Hybrid app like the ones done with cordova, phonegap, etc., then you can see all of its javascript source because it is persisted as a resource inside the "ipa" file. In addition you can alter that javascript code directly if you have a jailbroken device and find where the app is installed on file system (usually /var/containers/Bundle/Application/uuid_for_your_app/). However, I think there is no way to get that patched version and redistribute it (correct me if I'm wrong).
Currently we are only testing LiveCode 7.0.4 to see how it works and if we want to even use it. In our apps we need JSON from our server and have setup the mergJSON library/External in Livecode. So far, this is working very nicely in standalone tests for both MacOS and Windows. Today I started doing some simple tests on iOS and I am having a hard time with it.
I found answers where we need to use the Copy Files section in Standalone Settings, and that we need to copy the *.lcext file for mergJSON. Also watched the youtube how-to video that had mergSettings. There are no .nib files for mergJSON. Only .so, .dylib, and .dll, and the .lcext. I tried to add the .bundle file like the video, but the app will not launch, only black screen. Are other files required for mergJSON? And where do we put them? Do they stay in the same Externals folder structure or in project folder. Also, does an IOS runtime folder need to be created like in Widows/Mac? The app runs, no errors, but no JSON results are returned. I guess I am just a little confused on the Externals setup for iOS.
Just quick notes of our environment. We have Xcode 6.2 and the iOS Sdk 8.2. Live Code is 7.0.4 GPL (just testing and learning this way for now, will purchase commercial once I learn more.) I think the mergJSON I have is 1.0.15, downloaded from mergext.com. (which appears to be offline today) I have only tested on the simulator.
Thanks for any help.
You only need to include the lcext file in the copy files section of standalone settings. No need to setup a runtime folder for iOS etc.
The following use case:
create a strings file (not localized) and deploy the application to your test device
localize the file (en.lproj or similar), make some changes to the new file and remove the original file
deploy the application on the device
What I noticed that very often (always?) the application will still use the old non-localized file. The reason is that apparently the file is still in somewhere the application bundle, even though it has been removed from the project. iOS's logic is that if a file of a specific type is looked up, it first checks in the root of the bundle for the non-localized version, and only if it doesn't find it does it go deeper into the localized folders. (Is it just me, or is this logic kind of backwards? I'm used to first looking for language specific file, and then falling back to some defaults, but it might be my Java background.)
Sometimes (always?) removing the app from the device completely doesn't help either. What does in this case is a CMD+SHIFT+K, which cleans the build folder, and after the app is built and deployed again, the correct file is used.
A worse problem would be if such a thing leads to an app crash, like some strange issues with Nibs or whatever - I have seen those as well...
The question is: what would happen if the first version of my app in the apple store had the non-localized file, and the second version localized it? When the user upgrades the app, would they get the same behavior as me during development (i.e. outdated, non-localized file used)?
I can't imagine because I think this would be a cause of a lot of grieving and bug requests, but I can't tell for sure as I haven't yet published any iOS app.
If the behavior is correct when upgrading from the store, why is it? What is so different? Are the files stored locally on my computer somewhere and used when I deploy?
Can anybody share their experiences?
My application needs to load external swfs with ABC. I checked that this feature is available in AIR 3.7 and later. I managed to get the new SDK - 3.8 with the latest version of FD (4.4.3).
Now I am following this link: http://blogs.adobe.com/airodynamics/2013/03/08/external-hosting-of-secondary-swfs-for-air-apps-on-ios/
According to this post, "During IPA packaging, ADT extracts the ABC code from all child SWFs, adds it to the final executable and generates stripped SWFs in the “externalStrippedSwfs” folder created in the current working directory. The directory structure within the “externalStrippedSwfs” folder remains the same as specified within the text file. The generated stripped SWF’s should then be externally hosted on a web server of developer’s choice."
However, firstly, I could not find any such folder called "externalStrippedSwfs".
Secondly, even if this works, this means that everytime I have a new external swf to load, I will have to get it stripped off the code, put it in the main swf, and then upload the stripped swf (with assets). So everytime I do this, I need to "reupload" my app to Apple.
Are these assumptions right? My app architecture will need to be modified accordingly.
Yes, your assumptions are correct: You can't load an external .swf containing AS3 and have the app execute the byte code.
If we ignore the fact that it would most likely not be approved by Apple it can't technically work. The reason is because the Adobe AIR app doesn't contain a virtual machine capable of interpreting the byte code in the .swf:
When you build your application for iOS, there is no interpreted code
and no runtime in your final binary. Your application is truly a
native iOS app.
Source: http://www.adobe.com/devnet/logged_in/abansod_iphone.html.
You can do it! :) You just need to upgrade to AIR SDK3.8+ and follow the painful process.
The only limitation is that each external swif that you will be loading at run time, must be stripped by your ADT.
But you are right: you will need to update your app everytime your external content needs to be updated.
"externalStrippedSwfs" is arbitrary (name it as you wish I believe), you have to create that folder in your bin and run the command line from there.
Looks like Apple is not ready to lose the leash yet...