When should I be using NSInteger vs int when developing for iOS? I see in the apple sample code they use NSInteger (or NSUInteger) when passing a value as an argument to a function or returning a value from a function.

- (NSInteger)someFunc;...
- (void)someFuncWithInt:(NSInteger)value;...

But w/in a function they're just using int to track a value

for (int i; i < something; i++)
...

int something;
something += somethingElseThatsAnInt;
...

I've read (been told) that NSInteger is a safe way to reference an integer in either a 64-bit or 32-bit environment so why use int at all?

You usually want to use NSInteger when you don't know what kind of processor architecture your code might run on, so you may for some reason want the largest possible int type, which on 32 bit systems is just an int, while on a 64-bit system it's a long.

I'd stick with using NSInteger instead of int/long unless you specifically require them.

NSInteger/NSUInteger are defined as *dynamic typedef*s to one of these types, and they are defined like this:

#if __LP64__ || TARGET_OS_EMBEDDED || TARGET_OS_IPHONE || TARGET_OS_WIN32 || NS_BUILD_32_LIKE_64
typedef long NSInteger;
typedef unsigned long NSUInteger;
#else
typedef int NSInteger;
typedef unsigned int NSUInteger;
#endif

I want to allow users of an iPhone app to upload photos and use Amazon S3. There are 2 ways I see going about this:

1. Upload from iPhone to my server, which proxies it then to Amazon S3.
2. Upload from iPhone direct to S3

For option 1, the security is straightforward. I don't ever have to tell the iPhone my S3 secret. Downside is that everything is proxied through our server for uploads which sort of defeats the purpose of going to S3.

For option 2, in theory it's better but the issue is how do you enable the iPhone (or any mobile app on a different platform) to write into my S3 bucket without giving it my secret? Additionally, I'm not sure if this is a good design or not because the flow would be: iphone uploads to S3, gets the URL, then tells the server what the URL is so it can add it to our database to reference in the future. However, since the communication is separated into 2 legs (iphone->S3 vs iPhone->My-Server) it leaves it fragile as a non-atomic operation.

I've found some older info that references using Browser-based Uploads using POST but unsure if that is still the recommended approach. I'm hoping for a better solution where we can just use the REST APIs rather than relying on POST. I've also see the AWS iOS Beta SDK, but their docs didn't help much and I found an Amazon article that was equally unhelpful as it cautions you on what not to do, but doesn't tell you an alternative approach:

The mobile AWS SDKs sign the API requests sent to Amazon Web Services (AWS) in order to validate the identity of the AWS account making the request. Otherwise, a malicious developer could easily make requests to another developer's infrastructure. The requests are signed using an AWS Access Key ID and a Secret Access Key that AWS provides. The Secret Access Key is similar to a password, and it is extremely important to keep secret.

Tip: You can view all your AWS security credentials, including Access Key ID and Secret Access Key, on the AWS web site at http://aws.amazon.com/security-credentials.

Embedding credentials in source code is problematic for software, including mobile applications, because malicious users can de-compile the software or view the source code to retrieve the Secret Access Key.

Does anyone have any advice on the best architectural design and flow for this?

Update: The more I dig into this, it seems that a bunch of pople recommend using the HTTP POST method with the json policy file as described here: http://docs.amazonwebservices.com/AmazonS3/2006-03-01/dev/index.html?UsingHTTPPOST.html.

With this, the flow would be something like (1) iPhone makes request to my server, asking for policy file (2) server generates json policy file and gives back to client (3) iPhone does HTTP POST of photo + json policy to S3. I hate that I'm using HTTP POST in an apparently kludgy way but it appears to be better because it removes the need for my server to store the photo at all.

I've discussed this issue on the AWS forums before. As I say there, the proper solution for accessing AWS from a mobile device is to use the AWS Identity and Access Management service to generate temporary, limited-privilege access keys for each user. The service is great, but it's still in beta for now and it's not part of the mobile SDK yet. I have a feeling once this thing is released for good, you'll see it out on the mobile SDK immediately afterwards.

Until then, generate presigned URLs for your users, or proxy through your own server like some others have suggested. The presigned URL will allow your users to temporarily GET or PUT to an S3 object in one of your buckets without actually having your credentials (they are hashed into the signature). You can read about the details here.

EDIT: I've implemented a proper solution for this problem, using the preview beta of IAM. It's available on GitHub, and you can read about it here.

I have PDF files I need to prepare for viewing on mobile devices. The worse case would be ~50 pages, with lots full color images and vector art, file size approx. 40MB. This is acceptable for PC viewing on broadband, but not great for mobile viewing due to long download times and very laggy scrolling on mobile (At least on my overclocked Droid). Are there any tools or libraries for processing the files to simply the vector stuff, downsample/recompress the images, that sort of thing?

Output in pdf format is not absolutely essential, but it needs to be something readable on android and iOS devices without software downloads.

There are a few main things that can blow up the size of a PDF on mobile devices:

• hi-resolution pictures (where lo-res would suffice)
• embedded fonts (where content would still be readable "good enough" without them)
• PDF content not required any more for the current version/view (older version of certain objects)
• embedded ICC profiles
• embedded third-party files (using the PDF as a container)
• embedded job tickets (for printing)
• embedded Javascript
• and a few more

FOSS software: Ghostscript can try to size down your PDFs, mainy be re-sampling the pictures used and by removing older versions ("generations") of PDF objects which were replaced by newer ones:

gswin32c.exe ^
  -o sized-down.pdf ^
  -sDEVICE=pdfwrite ^
  -dPDFSETTINGS=/ebook ^
  -dEmbedAllFonts=false ^
  -c ".setpdfwrite <</AlwaysEmbed [ ]>>" ^
  -f blown-up.pdf

You can add more parameters to above commandline to size down certain PDFs even more (f.e. by setting a lower max resolution, etc.) Here is an example to enforce a downsampling for color and grayscale images to 72dpi:

gswin32c.exe ^
  -o sized-down.pdf ^
  -sDEVICE=pdfwrite ^
  -dPDFSETTINGS=/ebook ^
  -dEmbedAllFonts=false ^
  -dColorImageDownsampleThreshold=1.0 ^
  -dColorImageDownsampleType=/Average ^
  -dColorImageResolution=72 ^
  -dGrayImageDownsampleThreshold=1.0 ^
  -dGrayImageDownsampleType=/Average ^
  -dGrayImageResolution=72 ^
  -c ".setpdfwrite <</AlwaysEmbed [ ]>>" ^
  -f blown-up.pdf

Commercial+closed source software: callas pdfToolbox4 is able to reduce file sizes even more by applying a custom profile to the PDF downsizing process (it can even un-embed fonts and ICC profiles).

I know its been asked/answered before, but everything I look at is from back in July, or otherwise out of date.

Should I bother making my app compatible with iOS 3.x (probably 3.1.2 and up)? Means extra testing some coding changes, etc, etc.

Or are enough users on iOS 4.x that I don't need to worry about it.

If there are any sites that keep up to date (daily, weekly, even monthly) stats, please post.

DO NOT BOTHER.

You will find no difference in sales. It's a 4 world as of xmas 2010.