My question is... Can we use Xcode to create a tweak for jailbreaked iPhone? Foe example if I want to add some button in the lock screen how can I do? How can I mod the GUI of the default iPhone applications?
This is a really old question, but David is actually incorrect on most counts.
You can add custom UI to jailbroken devices, create tweaks without Xcode, hook into anything you wish, and more, without even having the source code for SpringBoard or wishing for it to be extensible.
MobileSubstrate is a code replacement platform that literally allows you to do anything. You don't even need to be an expert, but admittedly, having at least a moderate grasp on programming and Objective-C concepts helps a lot.
What you're talking about cannot be done. You're assuming 1) that you will have the source code for Springboard (lock screen), and 2) that those programs are extendable.
Without having the source code (it's proprietary), you cannot make "Tweaks" to the lock screen. You have nothing to compile into the lockscreen.
While you can mod them by editing the internal plists (simple things like show title bar or disable rotation), you will not be able to add functionality using XCode.
To create "tweaks" you would have to rewrite the lock screen entirely, or insert very low-level hooks into the Springboard/iOS. This is not possible via Xcode alone, since Xcode is not capable of even installing iOS-level apps (all installed apps are user-level).
You need expert knowledge of the private framework calls, and possibly be capable of disassembling and reverse engineering the specific program you're trying to extend.
Related
I have developed an app for the Android and it's working well, finally, and thanks to all the help from StackOverflow!!
Now I am being asked to make it work on the iPhone. I looked at iPhone a while ago but not recently.
What does everyone think? Should I take the time to learn Objective C and iPhone and port the app or forget it?
Are there any books that cross-reference functions so that you can look up how to do something in iPhone that you already have on Android?
From my experience in school, if you have already been able to create a working smartphone app in at least one mobile OS such as android, it wont take long before you can understand objective C and cocoa framework stuff. The only problem with that is you may probably need an apple developer license to use XCode.
So, I would say go for it since you also get paid, and also here is a link to iphone development guide for android developers : http://integratingstuff.com/2011/02/27/starting-iphone-development-as-an-android-developer/
Probably, it's better to get a partner who develop to iOS than doing it yourself.
Focus on a platform and let your products run to all users.
Unless you are using a framework that supports both iOS and Android (something like the Corona SDK) you won't have much actual code that will transfer over. Ideas, algorithms, logic, graphics, designs, etc will all transfer over just fine. Those are the hardest parts (IMO) of software dev.
Objective C (the language iOS apps are written in) is not that hard of a language to learn if you already know C-based languages (like Java). There are a few concepts that are different, but for the most part, it's not that bad. The biggest challenge for developing on iOS is buying a Mac. You can program for Android on Windows or Linux boxes, but iOS apps can only be developed on an Apple. Unless there is something that has happened in the Hacintosh arena that allows for iOS development on other platforms, you're stuck buying new hardware. BUT if you already have a Mac, download XCode and go to town!
Like Haphazard said, if there is enough money in it to make it worth your time, do it.
If you are getting paid, go for it! (Also, it could be a great learning experience.)
When I had to make the same decision, I considered the following criteria:
how much money is in the app on the other platform ?
how many times will this happen in the future, or is this going to be the only app? (how big is the benefit of learning the other platform for the future)
how much insider know-how is in the app that one is willing to reveal to another programmer porting this app (in my case I do mostly device handling apps, which is not really all that common)
what is the opportunity cost of spending time on porting an app instead of developing another profitable on the initial platform
If you have any possibility, you may look into similar apps and see how they are doing on the two platforms...
Good luck, whatever you are going to do...
I just learned about this and have not tested it yet, but one thing that you could do depending on the app you have you could take a look at PhoneGap. It looks pretty promising, though it may not work for your case with your initial application already made. But in the future this could help.
Unfortunately you will either have to re-write the app from scratch for iOS, or hand over the job to an experienced iOS developer. You can fairly easily port over the logic and computations in your app from Java to Objective C, but the user interface is the area where you cannot really re-use anything (except maybe icons), and the user interface tends to be a large portion of most apps.
As an Android developer who has ported several of my apps to iOS, I can say that this transition is a hard one. Firstly, you need to buy an iPhone and a Mac (if you don't already have these), since you cannot develop apps for iOS without the Apple hardware. Secondly, you need to learn how to use XCode and Objective C or Swift. And thirdly, since XCode ONLY allows creating the user interface graphically (as opposed to Android which lets you hand-edit the XML), there are many hidden things which can cause you to come unstuck. (UPDATE: Using the new SwiftUI approach to user interface design really helps with this last point, and in my opinion makes the transition from Android to iOS easier).
Finally the Apple and XCode environments seem rather alien to someone who is used to Windows and Android Studio. There are things like the Home and End keys having completely different behaviors to Windows which is frustrating. Also you have to use a combination of key shortcuts and mouse movements to hook up user interface elements to your code. Also, there are big annoyances such as the pop-up keyboard on iOS not pushing the content out of the way automatically like it does with Android. This is probably because Android is an OS designed for multiple screen sizes, whereas iOS is design for a limited number of screen configurations, but it makes iOS feel inferior and harder to work with from a developers point of view. (UPDATE: Using a ScrollView in SwiftUI solves the keyboard obscuring problem).
We're about to build an app for both iPhone and Android, and it would (of course) be glorious to only build one application that could work on both platforms. My question is, how easy is it to drop out of these cross-platforms into native code for certain views/activities?
In other words, if I find that Titanium is terrible for a particular task, can I just write that in Objective-C for iPhone and Java for Android or does that involve a bunch of hacks? I'm hoping we'll be able to build the basic stuff cross-platform, but I'd still like to be able to drop to native code if I start hitting snags or some hardware feature is poorly supported. We're leaning towards Titanium since we (as a shop) are unfamiliar with Ruby, but Rhodes is something we're definitely looking into as well.
From what I've read, the jury is out on these frameworks, so I'd like to have fallback options in case the app becomes buggy/unwieldy halfway through. I realize that a lot of this depends on exactly what you want to do with the app, but we're still trying to figure out what we CAN do cross-platform first...
you can write modules for each of the platforms, how easy it is to drop out and integrate them into you application would depend upon what you are trying to accomplish.
http://developer.appcelerator.com/doc/mobile/iphone/module_sdk
http://developer.appcelerator.com/doc/mobile/android/module_sdk
I have an iPhone application, now i want to convert that application to a universal application which runs on all the devices iPhone/iPod/iPad.
So, where to start, what things i need to do?
Any help, link, sample app, anything, will be highly appreciated.
Thanks in advance :)
I've done that recently, it's actually much simpler than it would seem. I recommend you read the iPad programming guide from Apple, it's about 100 pages in PDF (and you don't need to read all of it). Basically, you need to:
run a command in Xcode that automatically converts your project to Universal
add support for orientation changes, if you haven't done that earlier (it's required on iPad)
go through the app, see what's broken and fix it (e.g. it's likely that you'll see some places where you need to fix autoresize settings for controls)
That's of course if you don't want to redesign the UI for iPad, which you'll probably want to do in the end (e.g. use split views, popup dialogs and various modals, and do less full screen view transitions). The UI that you'll get by going through this steps won't feel 100% iPad-y, but it will work, and will look much better than an iPhone-only app zoomed in, so it's a good start.
I have an iPhone app and would like to create iPad version of it. What is the best way to setup the project when you want an iPhone and iPad version of the app?
I don't see that I'm able to use the same code base since the iPad version will have features in it that the iPhone version doesn't. It seems as though maintenance is going to go up with two similar code bases for the same app.
Refactor the common portions out and create a new target. You're the only one who really knows what the best way to do that is.
I just went through this thought process this week myself, having a published iPad app which I wanted to create an iPhone version of, and I decided on using the universal app approach. I found it worked extremely well for my needs. Once you get past the project setup issues, and the tactics of design decisions of where and how you are going to split up your iPad/iPhone specific code, the universal app framework is pretty fabulous.
Along the way, I created a reusable universal app project template, which I then used as the starting point for my universal app. The code is open source, hosted on github, I encourage you to take a look at it as one way to approach your problem, knowing that it is a tested solution that worked for me. (Additionally, I welcome any contributions from anyone wanting to help make it a more useful project)
The github link is: http://github.com/ryanscott/rcloudlib/tree/master/Samples/rcuniversaltemplate/
In terms of maintenance, I am extremely happy with the minimal added work it takes to support both devices. Sure, it's more work than supporting just one or the other, but it is significantly less maintenance than two separate codebases, where the business & app logic is almost identical.
In summary: I strongly believe that using a universal app is the best approach to creating an app that runs on on both the iPad and the iPhone.
Since the features should be similar but the layout is separate, code base s/b ok but the ib should change - making things far simpler; now v4.0 is a different answer :)
Maintenance would go up a bit. But if you have your app written abstractly enough, it should be fairly easy to port it to other devices. (For example, if you never assume that you will always know the screen size, you should be able to change that fairly easily).
For other things, it may be a bit difficult. However, if you use the Model View Controller (MVC) paradigm of thinking, you should be able to develop both apps simultaneously with only about 1/3 of the extra work. (Keeping the same model and controller, and only swapping out the view, alternatively, you could include the controller in there, but I wouldn't).
Note: This is the opposite direction to most similar questions!
I have an iPhone application which I would like to provide a demo of on the Mac. How hard is it to recompile (or rewrite) iPhone applications into Mac applications, assuming I intend to keep the same screen size, and not worry about making my application look "mac-like"?
Is it possible to distribute the iPhone simulator apple provides in the iPhone SDK with a copy of my application? Asking people to go and install it themselves seems like a major requirement.
On the whole most of the "core" frameworks are present on the Mac too. As a rule of thimb, any class starting NS will be present on the desktop - NSString, NSArray and NSObject etc. That hopefully means that all of your engine code will simply recompile and run.
The same is true of some middleware - all of iPhone Quartz will be present - classes and types starting CG... If you use 3D, there is OpenGL on the desktop but it is full OpenGL rather than the iPhone's OpenGL ES. There are some differences but your code will be pretty easy to port.
Where you will definitely need to recode is the UI. Not only because AppKit is not present but because the UI design you need for iPhone will generally not work on the desktop. The iPhone supports multitouch and does not have (meaningful) overlapping windows. Similarly, if you use any of the iPhone's hardware you will have to reimplement - the accelerometer and GPS are obviously not available on the desktop. In both these cases, the rule of thumb is that classes starting UI... are specific to the iPhone.
If you follow Apple's MVC design guidelines when you write your app, if will keep the UI related code well seperated from the engine code and porting should be easier.
First, you can't distribute the iPhone simulator. That's out of the question. The iPhone SDK agreement states:
You agree not to rent, lease, lend, upload to or host on any website or server, sell, redistribute, or sublicense the SDK, in whole or in part, or to enable others to do so.
You might be able to use parts of your program in the Mac version, but you'll probably have to rewrite UI-related code.
If your app is mostly OpenGL or custom views, probably not too hard at all. If your app using lots of UIKit views, then you will need to rewrite quite a bit to use the Mac standard Cocoa views instead. They are quite different.