With the push towards multimedia enabled mobile devices this seems like a logical way to boost performance on these platforms, while keeping general purpose software power efficient. I've been interested in the IPad hardware as a developement platform for UI and data display / entry usage. But am curious of how much processing capability the device itself is capable of. OpenCL would make it a JUICY hardware platform to develop on, even though the licensing seems like it kinda stinks.
OpenCL is not yet part of iOS.
However, the newer iPhones, iPod touches, and the iPad all have GPUs that support OpenGL ES 2.0. 2.0 lets you create your own programmable shaders to run on the GPU, which would let you do high-performance parallel calculations. While not as elegant as OpenCL, you might be able to solve many of the same problems.
Additionally, iOS 4.0 brought with it the Accelerate framework which gives you access to many common vector-based operations for high-performance computing on the CPU. See Session 202 - The Accelerate framework for iPhone OS in the WWDC 2010 videos for more on this.
Caution! This question is ranked as 2nd result by google. However most answers here (including mine) are out-of-date. People interested in OpenCL on iOS should visit more update-to-date entries like this -- https://stackoverflow.com/a/18847804/443016.
http://www.macrumors.com/2011/01/14/ios-4-3-beta-hints-at-opencl-capable-sgx543-gpu-in-future-devices/
iPad2's GPU, PowerVR SGX543 is capable of OpenCL.
Let's wait and see which iOS release will bring OpenCL APIs to us.:)
Following from nacho4d:
There is indeed an OpenCL.framework in iOS5s private frameworks directory, so I would suppose iOS6 is the one to watch for OpenCL.
Actually, I've seen it in OpenGL-related crash logs for my iPad 1, although that could just be CPU (implementing parts of the graphics stack perhaps, like on OSX).
You can compile and run OpenCL code on iOS using the private OpenCL framework, but you probably don't get a project into the App Store (Apple doesn't want you to use private frameworks).
Here is how to do it:
https://github.com/linusyang/opencl-test-ios
OpenCL ? No yet.
A good way of guessing next Public Frameworks in iOSs is by looking at Private Frameworks Directory.
If you see there what you are looking for, then there are chances.
If not, then wait for the next release and look again in the Private stuff.
I guess CoreImage is coming first because OpenCL is too low level ;)
Anyway, this is just a guess
Related
Intro: I have a Denon S-52 internet radio with an iPod/iPhone dock (the older 12V kind, so charging is not possible with newer devices but audio/control data is passed through). The radio has an external clickwheel-like control that worked beautifully with iPod nano/classic etc. Since the iPhone/iPod touch no longer have any clickwheel functionality, the signals from the Denon clickwheel no longer have any effect while playing (ie no seeking), but can navigate through some menus on iOS, and play/pause works. The few clickwheel apps I've tried obviously ignore the external signals.
Questions: How hard would it be for someone with no iOs programming experience (just C/C++/C#, plus an objective C tutorial from lynda.com) to develop a basic audio player app that would accept signals from the external Denon clickwheel to seek within an audio file (for my own use, at least at first)? I'm assuming this is possible because the signals are sometimes processed (as mentioned above), but I'd be happy to be proven wrong before I waste a lot of time and effort. I also assume a standard $99 iOS developer membership would be enough (since the device itself is already MFi)? Or perhaps an app that has this feature already exists?
How hard would it be for someone with no iOs programming experience (just C/C++/C#, plus an objective C tutorial from lynda.com) to develop a basic audio player app that would accept signals from the external Denon clickwheel to seek within an audio file (for my own use, at least at first)?
Nearly impossible. It's not just the challenge of figuring out how to access the dock connector and interpret the signals of interest. The real problem is that you want to use those signals to control music that's playing, and you're probably thinking of trying to control the iPod application rather than writing your own music player. Communicating between two apps is difficult at best, and probably not possible if the target app (iPod) doesn't provide a mechanism for external control. And the fact that you're new to the platform doesn't make any of this easier.
Your best hope is probably to file a bug with Apple requesting this feature and hope that they'll add it for you.
I was able to do this by jailbreaking my iOS device, which enabled me to access the serial port for iPod Access Protocol communication at /dev/tty.iap. Then I could incorporate something like the functions found in this iPhone Serial Port Tutorial (check archive.org if the link no longer works) to read the incoming signals and respond accordingly.
Update: An even better solution seems to be to write a tweak hooking into the iPodUI private framework and intercept the commands directly, and then message the Music player about what to do (see this post for more details).
I'll be working on a project in the near future to develop a relatively simple Bluetooth/Gyroscope application. The customer doesn't seem to know whether they want this to work on the iPhone or the iPod Touch and I have no experience working with either of the two- so it's best to assume they'll want it to work identically regardless of device.
I'm getting mixed results in my searches, some are saying that the iPod Touch does have a bluetooth chip or gyroscope and others aren't mentioning it. I assume the version of the device will matter, but I'm not sure what generation I'll be dealing with.
Are there any differences that I'll need to be aware of if I begin development with only one of the two devices? Also, what are the most widely supported development tools; my experience is obviously quite limited in this domain.
A good starting point is the iOS Technology Overview
The iPod Touch obviously lacks the phone capabilities and will more likely not have an active network connection as it only has WiFi. Bluetooth and Gyro will be there on both models (latest generation at least).
Can you make iphone apps without owning an iPhone? I have a macbook but wondered if maybe there was an emulator you could see your programs on to build your app. All the articles I found were a couple of years old.
Thanks.
You CAN use JUST the emulator to develop apps and for the most part, it works the same as the actual device. Memory and some hardware items behave differently on the device, so it can be be difficult to find bugs before the app gets into the hands of your users, and performance on the device will not be as good as the simulator.
Also, things like the Camera, Location Services, Accelerometer & Gyroscope will not be usable in the simulator.
In theory you can (Xcode comes with a simulator) but in practice I don't think you can. Several things don't work in the simulator or work differently so you won't be able to test if your app works properly.
The practical differences between the simulator and a real device are:
Runs faster than the real device.
Internet access is treated as WiFi. It doesn't emulate 3G.
You can't tilt or control acceleration.
You can touch with one or two (holding alt) fingets, but not more.
It doesn't vibrate.
Some sounds and musics don't run on the simulator.
Accelerators, camera, gyroscope, and GPS return fixed data. Your position reported is always Cupertino, the camera is blank, and the sensors report 0.
It can't be jailbroken.
Keychain doesn't work.
However, that's good enough in 90% cases to develop functional applications.
It is certainly highly recommended so you can actually test on a real device. Apple provides a pretty good simulator for doing the majority of your development on, but things like testing memory usages, performance and making use of features such as a camera, location api, accelerometer, etc, you'll need the device.
Certainly, start developing using only the simulator (if you are not sure you want to do iPhone development), but I would recommend getting a device (iPod Touch is a cheaper alternative) if you decide you want to move forward.
It depends on what you are trying to write. All functions of the device are not available in simulator. For example accelerometer. So if you need that then you can't work without the device. And also the simulator uses Mac environment which is far more powerful, both in terms of processing power and memory. So your app may run well on simulator, but may work poorly and even crash on device. So it's better to have a device for serious development. But obviously you can start learning on simulator.
If you want to write apps that don't suck you will need an iOS device. Period.
Doesn't matter if it's an iphone, ipod touch or ipad.
I never had an iPhone and wrote a dozen apps for it. In fact I still use my old iPod touch 2G for development.
But I wouldn't recommend that particular one for development, because now its end of life and you won't get firmware updates for it.
But last generation is totally fine.
I'm looking into possible means of efficiently creating an Android and iPhone targeted application from the same code base, be it in C/C++/C#/Objective-C or Java (using VMKit).
LLVM looks promising, however I'm slightly confused regarding compatibility issues surrounding the differing ARM CPU implementations, mainly from the aspect of how graphics and sound code are 'resolved' by underlying chipsets (i.e. do I have to code to specific ARM chipsets, or will a higher-level API, like OpenGL, suffice?).
I do know a little about various Cross Dev products (i.e. Airplay SDK, MoSync (GPL-GCC), Unity3d, XMLVM etc.), but what I'd really like to do is either write in Java or use a C/C++ engine, emit LLVM IR and create compatible ARM executables, if possible.
Apologies if any of the above is vague.
Thanks
Rich
The compiler is not the problem. To develop for both you need to create an abstraction layer that allows you to write a single application on that layer. Then have two implementations of the abstraction layer, one that makes Android api calls and one that makes iPhone api calls. There is nothing the compiler can do to help you.
Where LLVM IR might be interesting in its portability is for programs like:
int a,b;
a=7;
b=a-4;
Compile to IR then take the same IR and generate assembler for all the different processor types and examine the differences.
In the case of real applications that for example need to write a pixel on a display, the registers, sizes of the display and a whole host of other differences exist, and those differences are not exposed between the IR and the assembler backend but are exposed in the main C program and the api calls defined by the platforms library, so you have to solve the problem in C not IR or assembler.
LLVM is no different from any other compiler in the sense that you need, so I'm afraid the answer is no.
The LLVM IR is in layman's terms a "partly compiled" code, and can be used, say, to compile the rest on the end device. For example, if you have a graphically intensive app, you might ship parts of it in IR, then compile on the device to get the most performance out of the specific hardware.
For what you want, you either need to use one of the products you mentioned, or have native UIs (using Cocoa/VMKit), but possible share the data/logic code in the app
For standard app store legal development for stock OS devices, neither the sound nor the graphics code in an app have anything to do with the underlying chipsets or specific ARM CPU architecture. The sound and graphics (and all other user IO) are abstracted by each OS through platform dependent APIs and library linkages. You can either code to each platform's completely different APIs, or use an abstraction layer on top, such as Unity, et. al.
LLVM might allow you to optimize from intermediate code to machine code for certain differences in the ARM architectures (armv6, armv7, fp support, etc.), but only in self-contained code that does no user IO, or otherwise require any higher level interface use to the OS.
I'm analyzing the iPhone platform (for a paper). I've made a list with issues,
developers/architects have to consider, before working with the iPhone SDK.
The questions aims at people, who want to release iPhone software. What constraints restrict them in comparsion to other mobile platforms, such as Android, Windows Mobile, Symbian, etc.
Feel free to add hurdles, which I may have forgotten to list.
Thanks.
iPhone platform constrains/hurdles:
No physical keyboard
No replacable battery
One Application A Time
Sandbox File System
Restricted Deployment Cycle (Dev program...)
App Store Approval Process
No replaceable battery is no concern for software developers whatsoever, as there are no APIs for battery manipulation or replacement. This is no more of a concern for iPhone developers than "access to electricity" is a practical concern for developing for other platforms.
Others I would add:
Requires a Mac. Fairly obvious one, not a terrible barrier to entry compared to other closed systems like game consoles, but still higher than some other phone/mobile platforms like Windows Mobile, J2ME or Brew.
Costs money to debug on real hardware. You can only run and debug in the simulator unless you buy a $99 developer program subscription, which lets you pair iPhone and iTouch hardware with your Xcode install and run apps on it.
Objective-C as the programming language. It really shouldn't deter anyone but a lot of developers get really grumpy about learning anything new or different.
Must accommodate interruptions (i.e., the user may get a call at any time and the app must be prepared to save any state necessary and quit within a fixed time limit).
Not specific to iPhone but like any platform, you are constrained by the CPU/GPU/RAM the device has, and in the iPhone's case this is obviously quite a bit less hardware than people with a desktop background are accustomed to.
Restrictive wording in EULA regarding embedded scripting languages. It is apparently forbidden to execute any scripts via an iPhone application, which is quite a bummer as embedded scripting languages are quite common these days and very useful.
Limited CPU speed
Limited RAM
Objective-C is effectively the main
dev language
Power management concerns (I'm not sure if lack
of a replaceable battery is a concern
of mine). High CPU utilization can be a drain on the battery (and cause extra heat). In other words there are CPU intensive things I choose not to do, in order not to drain the battery too fast.
Only one IDE
inability to access other apps' data
easily