Understanding the IP Scanner Debug screen

Developer, News, Support

Networks can be amazingly complex; new protocols (and new twists on old ones) appear all the time.  We do our best to accommodate many common situations but sometimes the default configuration of IP Scanner may not be suitable for your network environment.  For example, multicast DNS provides better information with regards to device names, but does not always reflect actual public DNS records for your network segment.

The Debug window, which is accessed from the IP Scanner Help menu, provides a means for power users to tweak IP Scanner’s behaviour.

What are these cryptic options at the bottom?

DNS: enables DNS lookups.  Note: DNS lookups can generate considerable network traffic.
DIG: use DIG for DNS lookups (spawns separate threads) instead of system APIs, DNSServiceQueryRecord(), etc.
LCL: use local multicast DNS queries instead of designated DNS servers

MAC: only display devices that have a valid MAC address
ZZZ: enables support for Bonjour Sleep Proxy detection
NBT: enables scanning for NBT / Windows File Sharing
NDP: enable IPv6 scanning



Hey, my iPad has morphed into my Apple TV! (or … understanding the Bonjour Sleep Proxy Service)

Developer, News, Support, Uncategorized

Devices appearing to “steal” other devices’ network identities (and therefore also their customizations) is an unfortunate side-effect of network segments containing Apple TVs, Airport Base-stations and certain other devices that implement a network service knows as the “Bonjour Sleep Proxy Service”. This can lead to symptoms such as multiple, identical entries for some devices or individual entries switching IP numbers with alarming frequency.

Here’s why this happens: devices that typically are inactive on the network for long periods of time (cell phones, tablets, iOS devices, etc) go into a standby mode to save power. Since they do eventually need to respond to network requests, however, some of these sleeping devices use the Bonjour Sleep Proxy protocol to allow the Airport Base Station, Apple TV (or other device supporting the sleep proxy protocol) to take network requests on their behalf. For this handoff to work, the Airport must masquerade as the sleeping device by temporarily “stealing” its MAC address; the former then wakes up the sleeping device when it receives a network request intended for the latter and returns its identity so it can respond accordingly.

This behaviour makes those sleeping devices appear to have the same MAC address as the base station (or an iPhone suddenly turns into a second Apple TV, etc), leading to multiple entries with the same MAC address but different IP numbers and generally confusing scan results.

If you have a network that displays this behaviour, there are a couple of workarounds:

1) add those devices that tend to get hijacked as ‘manual entries’ – this will supersede the dynamically scanned entry. You can then optionally enable the ‘Display current Ping status’ preference to see if the device is actually currently present on the network.

2) disable network services that use the Bonjour Proxy, such as ‘Wake for Wi-Fi network access’ and other wake-on-demand services.

3) disable the ‘allow duplicate MAC addresses & IP numbers’ option in the IP Scanner prefs, although in some cases you may then get an incomplete view of your network.

4) be aware that this phenomenon exists; understand it and live with it – Remember: the technology exists in order to save power and make the world a better place!

More information: search for ‘Bonjour sleep proxy’ will return a number of more-or-less technical results. Here’s a pretty good primer for understanding and troubleshooting the service: http://stuartcheshire.org/SleepProxy/

Unofficial App Store Rejection Criteria


This aims to be a list of actual AppStore rejection criteria based on our, and hopefully your, direct experience.   Please add to this compendium by leaving your own rejection reasons in the comments and we’ll add them to the main list on a daily basis.

1) Vibration.   It is not permitted to use continuous vibration in your apps – short bursts as warnings is all that is allowed.   Don’t bother trying to set up a timer to keep the vibration going, it will cause your app to be rejected.

2) Linking to private frameworks.   This is obvious, but somehow in playing around with stuff we had linked to the MoviePlayer.framework.   That’s a no-no, and cost us about ten days while we unlinked that framework, recompiled, and then resubmitted.

3) Improper handling of editing in tableview cells.   Also obvious, but be aware that if you enable table cell editing, you’ll have to manually specify which cells should respond to editing controls and which should not.   We had some random prefs cells in one of our early apps that were able to be swiped to bring up a ‘delete’ badge.   Of course it didn’t do anything, but Apple justly considered this poor design and rejected our app.

4) Icons. Make sure the individual icons (in all size permutations) are identical to the 512/1024 pixel version. Also, use a different icon if you are creating ‘lite’ and ‘pro’ versions of your app (i.e., free and paid). Using the same icon for both sends your app straight to … you guessed it … teh bin. Apparently not true anymore according to some recent reports (Dec 2012).

5) Flatulence. Don’t even try. ’nuff said.    Now Allowed!  Hallelujah!

6) Copying existing functionality. This one is much more subtle and insidious, and has probably affected the great percentage of developers. In addition to the widely publicized Podcaster debacle, reports from user comments indicate that Apple is casting a wide net when looking for duplicated functionality. Mini web browsers, or apps that essentially show web pages, seem particularly vulnerable, even if they add new and/or useful functionality. Stay away from email clients as well.

7) Using appropriate keyboard type. If your app asks for a phone number or other numeral-only input and you present a keyboard that also includes the possibility of entering standard alpha-numeric input … yep. (Thanks Jeremy1026)

8) Version numbers. If your app is currently at version 0.99 or below, you’d better consider giving it a promotion as Apple seems to prefer 1.0 and above. One of ours was recently rejected for being .016, with a message suggesting that our version number wasn’t even numeric. When we resubmitted the same app from scratch as version 1.0, it went through.

9) Using Apple’s graphics in your own apps. Since Apple did such a tremendous job on the UI for the iPhone, it is awfully tempting to use their graphics and/or style in your own apps.  

Resist the temptation: we’ve heard of projects being rejected for using the Bonjour logo, as well as Apple’s network icon (the little picture of the globe with all the glowing lines), and others.  Even if you use Apple’s button images you may tempt fate if you use them in any way that is at odds with how Apple uses them.  For instance, the blue button with the “+” sign can ONLY be used to add a contact to a list – don’t try to use it for anything else.

10) Tableviews again. Victor Wang is REALLY picky about tableviews.  If you let a user highlight a row in order to select something or initiate an action, you’d better make darn sure that row is DEselected by the time the tableview is displayed again.  
Want to keep that row selected as a ‘feature’ (perhaps to remind the user which item they last selected)?  Not if you want your app to be approved by Apple, you don’t!

11) Network reachability. If your app uses a network connection, it is YOUR responsibility to tell the user if and when their device loses its network connection. In a recent appstore rejection screenshot, the Apple tester had clearly turned on Airplane mode, then launched the app. When the tester was only informed that the app could not log in, but not that the reason for the login failure was because of the lack of a network connection, the app was rejected.

12) Offensive language from your users. If your app has an interactive component that lets users post text, or if your app pulls user-generated content from the internet, it is YOUR responsibility to censor the language – otherwise Apple will censor your app right out of THEIR store. In a recent report, the Apple tester had written ‘F**K’ into a chat window, and then immediately disqualified the app for obscene language.

12) Use of private APIs. If it isn’t in the iPhone SDK documentation, you can’t use it. This is particularly frustrating for OS X developers moving code over to the iPhone because a lot of functions do work fine and you don’t even suspect that they could be off-limits for the iPhone. Nevertheless, here are some of those calls you might want to make sure are not in your codebase:

PS: for those who haven’t had the pleasure of interacting with Victor yet:
How Apple Decides whether or not to put an app on the App Store