An iOS Developer’s Wishlist
blog.cloudmagic.com
blog.cloudmagic.com
You should be able to send a URL to Instapaper or send a picture in Dropbox/Facebook/etc. without making either one your default "browser", "photo viewer", etc.
I think they should solve the problem, but I don't think the existing solutions are good enough.
More info: http://oleb.net/blog/2012/10/remote-view-controllers-in-ios-...
That's none of your damn business, app developers.
I think that in the long term that attitude is going to come back to haunt Apple.
Say what you will, but Microsoft always treated developers like its customers, not as some annoying beggars to be dealt with only under geneva convention standards, and no better.
The first set of requests from the OP makes is more general. Plus, I agree, the store really needs better search, but this will benefit both consumers and developers. Though honestly, search is already 100x better than it was just a couple years ago, so I am not worried they are not aware of that.
As far as analytics and review data go, MixPanel and Flurry have been amazing at tracking everything I've ever needed from app usage. The only use case I can see from Apple breaking apart iPad/iPhone from downloads becomes useful only when you have users who install apps but never launch them.
I really like the App Store now, it feels very organic with very visible editorializing going on.
You are entirely correct though. I would still love to be able to reply and do customer support in the comments and reviews like Google Play. Star rating need to go though.
It sucks to have retina assets full stop and it's only going to get worse as screen sizes change gradually and we end up with a huge number of legacy sizes. Now that ios7 is all about flat design, they could look at moving developers away from producing bitmaps which fit the screen and towards using repeated patterns for grounds and resolution independent artwork on top.
The vast majority of developers simply scale down icons and other assets to fit the various sizes Apple requires, so in practice the retina approach just means the same assets being scaled resized and cropped lots of times by developers to jump through the hoops Apple requires, and the problem is only going to get worse.
So I respectfully disagree, there are no easy solutions in this area, however I think resolution independence has better possible solutions than designing something as vector, then manually producing scaled rasters at every possible display size. At the very least Xcode should take care of that, but I'd prefer if iOS did, and accepted vector images within apps to start with - it could easily cache bitmap representations as it needs them, and then it could change those on the fly when screen sizes/resolutions change instead of requiring new binaries.
I'm not saying that Apple doesn't need to fix this, but there are some other approaches.
The App Store should take the good parts of the Play Store.
The fact that developers get to pick categories and that's not reviewed is a disaster. Let's look at the top board games:
3. Doodle Kingdom, some kind of puzzle game
8. Phase 10, a card game
9. Doodle God, another puzzle game
12. Skip-Bo, a card game
Other categories are worse. Minecraft (and it's clones) are near the top of most categories. It's basically impossible to find anything if you don't know the name ahead of time.
About videos: I rather if they'll allow animated gifs instead. Indie developers just don't have enough money to spend on videos and we'll lose to the bigger companies.
We cannot use the corporate profile as that requires the devices to be company owned and that is just not possible since we want to stay in compliance.
Google Play store launched a similar system this past year that has been very helpful to our Android testers. Now I'm just waiting for Apple to follow up with something similar.
Searching for an app in the App Store is a disaster.
If I were to search for music in the same way I search for apps, I'd never find anything I was really looking for. The terms are too broad. However, searching for music (even if using overly broad search terms) at least lets you preview a song, so you can judge if you're about to make a good purchase.
Fixed.
> require careful design, in order to maintain performance and safety.
In my experience, providing both performance and safety always requires careful design, regardless of the language being used. People who insist otherwise usually turn out not to have a very clear understanding of the state of the art with regard to either “performance” or “safety” or both.
This is especially true in the days of ARC, where you can't just store Objective-C types in C structs.
If it hurts when you do it, don’t do it. Some things need to be Obj-C objects. Many things don’t. I realize that this is glib, but it is absolutely possible to efficiently combine low-level “C-style” and high-level "message-passing/collections/object-style" Objective-C. It requires some attention to detail, but so do most things worth doing. As you build up good habits and idioms, it gets easier and easier.
Those are hardly the biggest problems when dropping down to C for data storage, construction, traversal, and analysis.
This is where Julia will shine for me. It will let me "drop down" to more efficient mechanisms when I need to write efficient algorithms, allowing me to use the same tools at all levels. This is actually my new plan for my IDE, I hope to embed Julia in it and rewrite most of the app in Julia. This should also make it dead-simple to let users extend the app by scripting it in Julia, while still having first-class access to the same internal ASTs used by the app itself.
[1]: https://github.com/sdegutis/Leviathan -- but don't use it, it's in a state of flux
They just happen to look like C code.
Quote from appendix B, grammar:
"This appendix presents a formal grammar for the Objective-C extensions to the C language—as the Objective-C language is implemented for the Cocoa development environment. It adds to the grammar for ANSI standard C found in Appendix A of The C Programming Language (second edition, 1988) by Brian W. Kernighan and Dennis M. Ritchie, published by Prentice Hall, and should be read in conjunction with that book"
ANSI C grammar is a subset from Objective-C's grammar.
This isn't just a pedantic point. You can't store an Objective-C pointer in a C struct, unless you cast it to a void* and bridge it. But then you're mixing ARC and non-ARC code in the same file, which is trickier to manage correctly.
It is an Objective-C struct that shares the same semantics as a C struct.
Similar to many other languages that have kept compatibility with C to easy code sharing between code bases.
Any line you draw between "C" and "Objective-C" is going to be arbitrary and generally useless. The only line that's supported by objective facts is assigning "C" to everything in the C standard, and "Objective-C" to the additions, but then that means that things like if statements, return statements, and variable declarations are "not Objective-C".
One of the problems I was remembering was how difficult and inflexible it is to write a fast and efficient AST in C and export it to a scripting language intact. The only viable way that I could think of was to convert the C struct to an Objective-C graph and export it to whatever scripting language via some bridging, such as JavaScriptCore.framework (ugh JSExport) or maybe MacRuby, or similar.
But writing the AST in Julia itself might very well solve the fast/efficient problem, and since it's a dynamic language, scripting comes for free, with a first-class AST.
Another problem was how I couldn't mix Objective-C and C semantics when writing my AST. If I wanted to represent a collection in my AST, I had to basically hand-roll all the methods in NSMutableArray myself.
So ultimately I'm not sure I expressed myself properly, but I'm still excited about diving into Julia as a scripting language. I really believe it could solve this kind of problem. I can imagine new platforms being built with very little supporting platform-specific code which exports a few building block APIs to Julia and lets the script to the rest.
You just have GNUStep, which still seems to be at the same level I tried to used back when WindowMaker was my desktop (1999-2003).
Additionally it is not easy to find out how much of Objective-C, given Apple's changes, is actually supported by clang and gcc.
I love the ability to write apps in C#. The language is amazing. However, it can be exceedingly difficult to use 3rd party libraries in your application. It is possible - you can generate bindings for static libraries, but sometimes you run into solutions you just can't solve.
Also, all the tutorials you run into on the web are using Objective C. So you still have to know the language. The Xamarin community is practically dead compared to the vibrant native ecosystem that iOS enjoys.
Ultimately, I'm rethinking the decision to go Xamarin, and I am considering going native.
What I'll miss: Ability to have Android and iPhone apps sharing a common codebase. C#.
I have my issues with the language, but all in all, I do like it.
Additionally, it is supported out of the box in all mobile OS SDKs.
1) Device testing without a dev account or jailbreaking.
2) Xcode on Windows and Linux.
I don't think these are unreasonable!
I wish they would let users install their applications without a dev account. I really don't want to pay $90 just to be able to do that. Being able to sell your apps on the App Store would justify the price, but otherwise it's quite unreasonable.
App installation could work over https similar to TestFlight.
SO yeah, lots of missing pieces in there too I'm sure, but doesn't seem impossible if you're feeling up to the challenge.