[afternooner]

It could be a bad sign, or it could speak to priorities, and your priorities are not their priorities it seems. Personally, I accept all pull requests that are solid, written to my standards, fix or extend a feature that is a priority, are accompanied with unit tests, and do not impact or impinge on another feature or future feature. I do not however accept all pull requests. Part of this is that if there is no demand and it's a single individuals edge case, then I'll very heavily scrutinize the patch. If I don't agree, don't understand exactly what every line is doing, or do not feel it will be used by a significant portion of the user base then I won't pull it. Because moving forward, I will have to maintain it, and that isn't free. And if people don't like that, they can fork it.

[danielsju6]

True, but if your business is alternative toolchains to Apple's own; and it's shown to me that you don't support something I know a great deal of iOS developers use then I lose a bit of faith in your marketing message that "lot's of important apps use us... and don't mind what all the naysayers say about our garbage collector, give us $200/year and give it a shot yourself".

It's one thing that my pull hasn't been accepted, the other bigger concern is the nature of the unpatched code that says to me that no one serious has used Ruby Motion. We aren't talking a hobbyist open-source project here, this is a partially open-source commercial offering.

Source: I am a Ruby developer who has to develop native on occasion... and I run a company who's job it is to deploy beta/in-house applications to mobile devices. I just ran a quick sql query and 43.7% of the hundreds of thousands of applications we host are deployed with enterprise provisioning. I wouldn't call this a personal edge case.

[afternooner]

Enterprise and government comes with a lot of baggage that no sane developer would ever try to take on. You are manifesting your priorities on them, and that simply may not be the case. The $200 price point is likely that high in order to keep the client base low. I'm not saying you're wrong, but Apple itself barely supports enterprise with most of their enterprise management bits being third party. A laptop without a docking station??? Crazy, they might as well not sell computers...

Source: Work for government, not entirely sane, have had Apple reps brought in to discuss in house dev, written in house application, ruby, C#, C, Obj-C, JS, C++ developer in order of preference.

[danielsju6]

On iOS "enterprise provisioning" means less baggage. No UDIDs, which are deprecated in software BTW. To be clear this is a tiny patch that adds support for some 40%+ of dev shops and all enterprises. All we are talking about is this:

  unless App.config.provisions_all_devices? || App.config.provisioned_devices.include?(device_id)
    App.fail "Device ID `#{device_id}' not provisioned in profile `#{App.config.provisioning_profile}'"
  end

Where the provisions all devices is my bit supported by a single line helper, it's not scary. If you have more than 100 devices beta testing your app you use enterprise provisioning PERIOD, it doesn't have anything to do with classic "enterprise" except you need a DUNs and to pay Apple an extra $100/year.

Almost every dev shop that is more than two guys I know uses this.

[banister]

whose