Answering myself -- apparently this was a bug in app store connect, because as of today, I was able to create an IAP with a product ID with dots in it as expected. I did not see any acknowledgement of the issue from Apple, but maybe I missed it.

I think I just ran into this issue in native objective-c code. I am not using swift. I defined a category on UIButton and created a setTitle method: @interface UIButton (utility) (void) setTitle:(NSString*)title; @end And my code never gets called. I finally changed the name to "setText". I really want to know why this is breaking. It makes me worry that using categories is just plain dangerous. Especially if an upgrade of the OS version could potentially break an app that is already distributed because of this type of problem. After change the name to "setText" I added some debugging code to probe for a selector named "setTitle:" and sure enough, there was already a method, presumably defined by Apple. Here was my code:   if ([button respondsToSelector:@selector(setTitle:)])  {   NSLog(@"xyz: has selector setTitle:");  }  else  {   NSLog(@"xyz: DOES NOT have setTitle:");  } And it did log "xyz: has selector setTitle:". I am thinking that either Apple created a new PRIVATE method "setTitle:" or their own extension to UIButton (or sub-class) named "setTitle:". I lean towards the extension since I believe that a naming conflict with extensions causes ambiguous behavior. But I would like to know what it going on. In the end, I just wish they would add the official method to UIButton for "setTitle" without the state parameter so we would not have to "patch things up".

I answered my own question about whether this is an issue with actual devices: it is. Got an iOS 12.4 iPhone and tried out my app. It crashes in the same way. I ended up having to work-around this problem by checking the iOS version at run-time and skipping making this call if the iOS version is less than 13. Fortunately for me this call is not critical to functionality -- more of a debugging thing.However this does point out a lack of testing on Apple's part. They need some automated tests before iOS release to ensure that the actually exported symbols in a framework match the declared information in the header files for the framework. In this case there is a mismatch that is pretty serious as it will cause app crashes when an API that does not exist is called by an app. And I doubt that most app developers test on ALL versions of iOS that they actual "support". Presumably if Apple is not testing this, an accident could cause an API to disappear in a micro iOS update. Maybe they already noticed this and now test all iOS 13 releases in this way -- let's hope so.