Do NOT embed a single API key in the app. Your concerns are valid regarding the effect of malicious users. Also, you have a serious vulnerability in your current setup where you could have a malicious API user change other user's preferences by providing fake UDIDs.
Instead, create a "registration" service that is called upon first time app startup on the device which generates and returns a GUID based on the UDID. Store the GUID in your device local user preferences and on the server. Keep track of the GUID and match it up with the UDID on every request on your server.
Make sure all of this occurs over SSL.
With this approach there is no embedded master API key to be abused. Also, you can blacklist abusive users by flagging GUID/UDID combinations and you can also eliminate your existing issue of potential masquerading of existing registered devices. However, you cannot prevent malicious registering of devices that have not already registered with your service. That will always be a potential hazard of using a device id as a user identifier.
There are even better and more established authentication mechanisms that take a better approach, ie. OAuth, JSessionIDs, etc. that you should take a look at.
Also, in the future you should not be using the UDID to identify your users since access to it has been deprecated. You can mimick the UDID for your purposes by creating a custom device GUID on the device upon application installation and saving it in your local user preferences.
与恶龙缠斗过久,自身亦成为恶龙;凝视深渊过久,深渊将回以凝视…