Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Apple Relaxes iOS Restrictions On Development Tools, Publishes Review Guidelines

apple.com

Post reply on HN
Print view View original

201–210 of 240 posts

Re: Apple Relaxes iOS Restrictions On Development Tools, Publishes Review Guidelines

#201

Post by jrockway »

cardinal23 wrote: post #99
jrockway wrote: post #76

Earlier quoted context omitted.

Thanks for posting these. Still too many rules for my taste. (Google also has too many rules, FWIW.)

Instead of just saying too many rules, do you have points in the list that you object to? One of the problems with rejection until now was the lack of specific guidelines about what would be rejected. It seems to me that a comprehensive document would unavoidably have many rules, and the prohibitions that I read seemed reasonable.

The tipping point was "no card counting". While card counting may be against the rules at a particular casino, it's not illegal in general and does not belong in the "legal" section.

Whenever Apple is confronted with a situation where the user could use a feature or tool for something that's "against the rules", they tend to disable the feature. See, for example, iTunes' inability to import music from an iPod. It could be 100% legal for me to do that, but Apple doesn't provide that feature, even though iTunes "knows" how to do it.

(I stopped using Apple products about 5 years ago when they added PT_DENY_ATTACH.)

Re: Apple Relaxes iOS Restrictions On Development Tools, Publishes Review Guidelines

#202

Post by [deleted] »

tptacek wrote: post #104
ohhmaagawd wrote: post #36

my guess is the FTC investigation into Apple's practices got them nervous. better to just cave than deal with anti-trust issues: http://voices.allthingsd.com/20100611/ftc-to-investigate-app...

My guess is that only Apple knows why it changed the rules, but that anyone who can do a Google search can (a) read up on what antitrust means and (b) observe Apple's non-commanding share of the mobile market.

[deleted]

Re: Apple Relaxes iOS Restrictions On Development Tools, Publishes Review Guidelines

#203

Post by msbarnett »

new2 wrote: post #195

The death of Objective-C as far as iOS development goes?

Seems unlikely. It's always been possible to create Mac apps in, say, C++ using Carbon or Qt, but ObjC/Cocoa has remained very popular despite that.

It's an exceptionally good and low friction framework that people tend to like. Most of the anti-Objective-C sentiment seems to come from people offended at the notion that they might be required to learn something new rather than stay forever in their comfort zone.

Re: Apple Relaxes iOS Restrictions On Development Tools, Publishes Review Guidelines

#204

Post by notahacker »

tptacek wrote: post #196
notahacker wrote: post #190

Earlier quoted context omitted.

Microsoft's monopoly was only on Windows, which just happened to be the only viable option for most PC OEMs and browser developers. If owning 99.4% of the mobile app sales market (Gartner figure for 2009) and imposing restrictions which hinder the development of cross-platform apps doesn't deserve antitrust scrutiny, I'm really not sure what does.

No, it was the only option for most PC OEMs, because Microsoft adopted anticompetitive licensing practices that explicitly punished OEMs financially for distributing anything but Windows with prominently-placed IE. Apple cannot control 99.4% of the mobile app market, regardless of what their current revenue share is, because they still control less than 30% of the market for app platforms. If Apple attempted to abuse…

OEMs wanting to offer a non-IE default browser had the unattractive options of switching Linux or incurring the financial penalties; iPhone developers barred from using "cross platform" tools had the unattractive option of switching to platforms that have shown relatively little potential to generate revenue or higher development costs.

Because of their store cornering the market for paid apps, Apple is in the enviable position of being potentially able to reduce development on their competitors' platforms, thereby making customers less likely to switch as well as worse off overall. Irrespective of the letter of US antitrust law, that is something I feel _ought_ to be kept under scrutiny.

Re: Apple Relaxes iOS Restrictions On Development Tools, Publishes Review Guidelines

#205

Post by jf »

gcheong wrote: post #88
jacquesm wrote: post #21

So, how about all those people that were supporting apples' right to run their app store the way they see fit and who said that there is no point complaining about it? I think this proves that complaining about stuff like this is well worth the effort, assuming that that - and not some backroom pressure - is what caused them to back off. They mention it in their release so I figure it must have been a major factor. e…

Periodically Apple sends a survey out to iPhone developers asking for feedback on various aspects of the developer program and App Store. This latest move by Apple gives me some hope that they aren't just round-filing the feedback.

As someone who works for a large software company. I can assure you that feedback from developers is not only hard to obtain, but highly valued and used to shape future decisions.

From my personal experience, people "in the trenches" use feedback from their constituents to add weight to their messages to their superiors.

Re: Apple Relaxes iOS Restrictions On Development Tools, Publishes Review Guidelines

#206

Post by brownleej »

elai wrote: post #161

I hope they add searchability to in app purchases soon. If you make travel guides for many countries, it looks like you can't sell them as separate apps easily anymore. If someone searches for Bali, it's going to get missed if you make a travel guide for Bali and 50 other regions.

Couldn't you just list all the countries you support in the app description?

Re: Apple Relaxes iOS Restrictions On Development Tools, Publishes Review Guidelines

#207

Post by pbz »

MartinCron wrote: post #103
sourc3 wrote: post #90

Earlier quoted context omitted.

Having programmed in C, C++, C#, Java and JS (if scripting counts) I applaud this. I have tried to get used to Objective-C but after using C# for the past 4 years or so, it just seems uncomfortable with me (probably a personal bias that cannot be generalized). I was considering developing my startup's first mobile app in Android since I did not want to touch Objective-C and go with an iPhone Web Page. Considering the…

Accidental downvote. Meant to upvote. Totally agree. Damn iPhone.

I would say it's also poor UI, even with a mouse is easy to hit one over the other without a way to undo...

Re: Apple Relaxes iOS Restrictions On Development Tools, Publishes Review Guidelines

#208

Post by rabble »

rabble wrote: post #97

I've got 5 apps which were submitted by not approved by the time this 3.3.1 rule was released. Those apps have been "In Review" for this whole time. I've got another couple dozen apps, which we have been preparing for android, but could easily submit for iOS. Most of these are unique games, but we've build a few on our own from scratch. This is great news. But that said, we're still all at the mercy of Apple's changi…

They all got approved. Yes! Finally getting something for that work, we'd given up on it.

http://oneappatatime.com/games/published

Re: Apple Relaxes iOS Restrictions On Development Tools, Publishes Review Guidelines

#209

Post by allwein »

ataggart wrote: post #187

It's 2010; is there any valid reason why a web page announcing a change to another document doesn't link to that document? Assuming this[1] is it, what exactly counts as a "private API" per section 3.3.1. Isn't any code I write a private API, thus calls to it a are violation? And how is that compatible with the allowance in 3.3.2 to package an interpreter into the app? [1] http://developer.apple.com/programs/terms/io…

This strawman comes up every time we have a discussion about the developer agreement. The section referencing "private" APIs is talking about Apple specific APIs which have not been publicly documented. In Apple nomenclature, Public="class, methods, and properties are documented in the reference library and exposed for developers to use." Private="undocumented and exposed for Apple internal purposes only". Basically, if you can find it mentioned in the documentation, you can freely use it. If you had to do a class dump or use introspection to even find the method out, it's probably private.

Re: Apple Relaxes iOS Restrictions On Development Tools, Publishes Review Guidelines

#210

Post by allwein »

magicseth wrote: post #135

An important Caveat is Section 1 and 10.1: The Human Interface Guidelines. This is large document that describes in general the "look and feel" of apps that run on the iPhone. If you make something that doesn't fit with their long-term vision, or irks them in some other way, it is extremely easy for them to say "You are violating the Human Interface Guidelines," and leave it at that. This has prevented me from delive…

Would you care to share what sort of "innovative UI experiences" you've been prevented from delivering?
Post reply on HN