I'm using sharekit for twitter integration. Application works fine with sharekit but compiler shows 25 warnings for semantic issues. Since app is running fine,is it ok to leave this issues without fixing them? Will leaving those issue crash the application for some users?
As a general programming principle you should have no errors or warnings... Many programmers consider any warning an error... Personally I like to see 0 warnings... They are telling you something...
Make sure, that you use latest ShareKit 2.0. There is only one warning left, coming from 3rd party API. If you decide to use try it, the best might be to reimplement it from scratch and follow install wiki. There were many changes since the original share kit.
Related
I installed pod JSQMessagesViewControllerin my Swift project but now I don't need it any more. I do not want to remove it to cause any side effect. Is it alright if I just leave it there and do nothing? Thanks!
Yes, it won't hurt anything. However, it will make the binary larger than it should be due to unused libraries. Also can be confusing later for others looking at the code why a particular library is there. But, the app will not break because of this.
If you aren't making any reference to this framework it shouldn't cause any side effect if you remove it. I really recommend you to remove anything that is no longer used. It's a good practice to avoid problems with future iOS versions when building your project and also makes your app lighter for users with a quicker download.
Just go ahead and remove the pod.
If you truly do not use it, your project will run without problems.
If you do actually use it without knowing about it, your app will most probably not compile, which is a great time to either remove the reference to the pod, or re-add it if you realize that you actually are using it.
If you do actually use it without knowing about it, your app may compile (e.g. if you refer to it from a xib or a storyboard), but will crash when trying to use the non-existing pod. This is much better than keeping on using the pod without knowing that it affects your project.
Good luck!
I need to obfuscate my iOS mostly C and Objective-C based app.
https://github.com/obfuscator-llvm/obfuscator/
llvm-obfuscator provide quite well solution without much additional work related. Obviously it will not prevent people from reversing it but at least it will lift a bar a little. App it self is designed good enough to protect few security related mechanisms but I would like to compile it with custom compiler to make it even more harder. But it raises few questions
If apple actually allow compiling with custom compilers
How it may affect speed and stability of application, o-llvm is
quite old 3.6.1 while apple already published their llvm 8.0 - not
sure what has been added improved or changed
o-llvm does not support latest xcode. I have abandoned idea and wrote my own obfuscation script which encrypts all variables and methods except Cocoa ones. It's not that good like o-llvm but it works great.
EDIT: this question is outdated - TwitterKit is now available via CocoaPods
It seems to involve downloading an application, giving that application the path to my project, and adding one of their executables as a build phase.
It seems like that requires placing a lot of trust in Fabric...
Is there a good reason they're not providing the option to download TwitterKit in a more standard way, like a framework or a cocoapod?
Great question, the short answer is that we built the application to reduce friction when implementing any of the kits (TwitterKit, Crashlytics and MoPub).
Longer answer - there are various reasons for the Fabric application vs a "native" implementation. Currently the Fabric application provides a bunch of functionality that reduced friction for folks trying to implement any of the kits (i.e. Crashlytics, Twitter and MoPub). On the Crashlytics side we do a variety of things like take the dsym to replace the symbols in the crash logs with the appropriate methods names so crash reports are readable (also this makes it v.easy to provide a linkage between accounts, without the need for a key variable in the code). On the TwitterKit side it's fairly similar story, rather than take measures to get your keys/secrets from apps.twitter.com you can simply use the application that does some heavy lifting.
You can rest assured that the team isn't trying to do anything shady here. Feel free to reply here if you have any questions :-)
You are also free to download Twitter Kit as a CocoaPod: https://cocoapods.org/pods/TwitterKit
Just add the following to your Podfile:
pod 'TwitterKit`
ShareKit looks abandoned. And there are so many forks. But major maintainer is undeterminable. Now I'm just going to pick one to use. What fork do you recommend? Or replacement?
try ShareKit, they are trying to make the ultimate "best of" fork. ShareKit release 2.0 is in final testing.
Socialize is a new social sharing sdk by the folks behind AppMakr. It's open source and appears to be free. I haven't tried it yet - so I can't vouch for it - but maybe it's worth a look?
As of lately, ShareKit hasn't been working on iOS5 so I had to remove it from my app. Facebook has actually released their own class and it's looking pretty sharp so far. Check it out:
https://github.com/facebook/facebook-ios-sdk
I'm using the last official release in my application. Works fine though. You can just add new social networks to the kit yourself if needed.
I've developed and application for iPhone. It works fine on os4 but it does not work on os3.1. In fact works but there are some problems; after splash screen a what screen appears. while I leaving the application I can see the application is opened successfully but just see while exiting.
So I wonder if there is a tool which says which apis have problems with os3.1? So I have a chance to replace them.
If you want to check a specific API, just run this in your code somewhere with an appropriate response. For example, to see if print is supported, run this...
if (NSClassFromString(#"UIPrintInfo")) {
}
Set your project's Base SDK to iphone-os-3-1, then build. All the error messages about classes, methods, and functions that don't exist must designate things added since iphone-os-3-1, since your project built and linked fine against the iphone-os-4-0 SDK.
If you don't have the iphone-os-3-1 SDK, try this instead:
Open your project's Build Settings.
Find the "Preprocessor Macros" setting.
Edit it and add __IPHONE_OS_VERSION_MAX_ALLOWED=30100
Now, try building. This should cause everything introduced after iOS 3.1 to be labeled unavailable, producing the same errors as if you had switched to the iphone-os-3-1 SDK.
It's a good idea to get a second installation of Xcode for this situation, in this case you need 3.2.1 with SDK 3.1.3 - I wish I could help you with a download link since it is no longer shown on Apple's page, but I have googled in the past and found direct, official download links which will work as long as you are signed in with your developer account, so good luck.
The annoying bit is that you need to go through your project files and set "Base SDK" to 3.1.3 and then back once you have completed the exercise. But it is the easiest way to flag what you can't do in 3.1.3. "sudo rm -rf" (I feel nervous even typing that) has an excellent method there but you need to have an inkling of what might be safe and what might not before you implement it or else you end up with code 10x the size it needs to be.
Apple really needs to sort out this issue - hopefully by flagging methods that are prior to your specified "Deployment Target", in the same way that deprecated methods are flagged.