Logbook Pro for iPhone crashing, and other comments...

PilotFlying

Well-known member
Joined
Jul 17, 2006
Messages
72
Location
Toronto, ON
Hello Neal,

First, I must say, great job with Logbook Pro for iPhone! I've been a Logbook Pro user for many years, and have been eagerly anticipating this addition for a while. The sync to/from the 'cloud' is pure genius.

However, since the update to v1.0.2 with multi-tasking support (and continuing on the latest release, v1.0.3), I've experienced multiple crashes and other strange behaviours. I've yet to be able to pinpoint the exact circumstances that lead to this situation, but as far as I can tell it seems to correspond with the transition from airplane mode ON to OFF. Several things have happened in this case, on several occasions:

(1) After entering a flight on the 'Flights' page and returning to the 'Home' screen to sync by pressing the back arrow, the app freezes. In some instances, a few minutes later it will subsequently unfreeze, but then incorrectly show the contents of the 'Flights' page on the 'Home' screen (I can tell it is the home screen because the 'Sync' button shows on the top left instead of the 'Home' back arrow - see 'photo_4.PNG' attached). In other instances, it will show the contents of the 'Home' screen on the 'Flights' page ('photo_3.PNG'). The only way to then fix this situation is to completely close the app from the multi-tasking tray and then relaunch the app. Sometimes the last flight entered will still be there (if it got the sync in before crashing), but other times not.

(2) Sometimes, when entering an in/out time, the time shown in the in/out field after being edited is shifted by several hours from what was actually set on the selector wheel; i.e. 21:20 selected, 19:20 displayed. 'photo_2.PNG' attached shows the result of entering a time of 21:20 ('photo_1/PNG'). My best guess at this one is that it has something to do with a change in time zone from the time airplane mode was turned on to the time is was turned off, as it only seems to happen after crossing multiple time zones, and the difference between the selected/displayed values seems to correspond with the time change. The example above occured at the end of a flight from Calgary, AB to Ottawa, ON - exactly 2 hours apart. Again, the only way to fix this problem is to completely exit the app and then relaunch.

On another note (not so much a bug report but a question/suggestion): since the addition of multi-tasking, the 'Sync on Start' and 'Sync on Exit' options no longer have any effect, as the app never really starts or exits. This means that the automatic syncing function doesn't work, and a manual sync must be initiated from the home screen (which has proven a slight problem due to the crashes reported above). Is there a way that you could initiate a sync any time Logbook Pro becomes the active app, and then again when closing to the background (in essence achieving what you were originally intending before the advent of multi-tasking)? Or maybe upon clicking 'Save' from the add flight screen? Or am I missing something as to how the current setup is supposed to behave?

Please let me know if you need any further information from me. Hopefully you will find a fix for these issues soon, as it is proving to be a bit difficult to use the app as it is right now. The thought of being able to enter flight details in Logbook Pro while multi-tasking is wonderful!

Cheers,

Chris Brunner

Note: These issues were also submitted as a technical support ticket (ID VMR-110458).
 

Attachments

  • photo_4.PNG
    photo_4.PNG
    61.6 KB · Views: 54
  • photo_3.PNG
    photo_3.PNG
    36.4 KB · Views: 57
  • photo_2.PNG
    photo_2.PNG
    42.7 KB · Views: 59
  • photo_1.PNG
    photo_1.PNG
    45.4 KB · Views: 58
Hello Chris,

Thank you for the compliments on the app. As to the Sync on Start/Exit, these issues are resolved in 1.0.3.

As to the time zone changes when switching in/out of airplane mode, I think this is just a function of the application being started in one timezone and there's nothing I can do about it but I will certainly investigate and see what I can find. When the application starts, and you'll probably see this in other apps, the application picks up the time zone and will continue to use that until the application is stopped and restarted. The only way around this is to finish your work then terminate the app manually and not let it suspend (double-tap the home button then tap and hold and remove the app from the multi-tasking tray).

As to the other issues, I'm not able to reproduce this. Are you using an iPhone 4 or prior hardware? I think what's going on is your device has too many apps suspended and is probably running low on memory. On my iPhone 3GS I clear apps I'm not using as for some reason Apple is suspending everything which is a design flaw in my opinion. It eventually causes things to become unstable, "choppy" and inefficient. I'm sure they will improve this in a future update of iOS 4, I can't see any PDA suspending every app that runs and never doing any cleanup. If I could reproduce this I could fix it but I have never seen anything like the images you show since the first day of development. So if you see this, try clearing your suspended apps or power cycle the device (reboot) and see if that alleviates the issue.
 
Hi Neal,

Thanks for the quick response; great support - another reason to love your products!

I'm going to go out of order here and start with the freezing/wrong screen issue. I just tested this again this morning on a flight from Ottawa, ON to Winnipeg, MB, which are 1 hour apart. I did as you suggested and terminated all apps, followed by a reboot, so that Logbook Pro was the only app running. This time, I didn't experience the weird screen behaviour. I'll keep monitoring it and let you know if the issue pops up again.

In regards to the issue with the discrepancy between selected time and displayed time, I'm not sure I understand how the app's internal time has anything to do with it. I understand what you're saying that the app's internal time will stay locked to the time zone where it was started. But isn't the current time (app, actual or otherwise) irrelevant when it comes to entering an in/out time? If I say the in time is 19:20, the in time should be 19:20. That is, unless, I use the 'current time' blue arrow, which I do not.

Right now I'm a little stuck as to how to use this app. In my ideal situation, I would turn airplane mode ON before departure, enter as much pertinent information as possible while airborne, turn airplane mode OFF again on arrival, and then close out the entry when I have time after that. The whole point of multi-tasking is to be able to enter data as time permits. I can't think of any work-around that solves the problem: If I close out the entry before turning airplane mode back OFF, my data won't sync. If I leave airplane mode ON, I will run into the time zone issue, not to mention that my battery will be dead after 4 hours of searching for signal. If I complete half of an entry and then terminate the app and restart in the new time zone, I will lose my half-completed entry as, in my experience, only synced data will be preserved. The only thing I can think of is to do the whole entry at the end of the flight in the new time zone, but then I may as well just wait until I get home and enter it directly into Logbook Pro on my PC - completely defeating the purpose of the mobile version.

You mentioned that v1.0.3 fixes the automatic sync issue with multi-tasking. Could you please explain what the new logic is as to when the app will automatically sync? I did some tests and still had some problems:

(1) After creating a new flight entry and exiting the app, the flight did in fact appear in my 'my sync' portal; however, upon re-entering the app, the entry still appeared as black, and not in grey which would represent it has been synced.

(2) A flight deleted within the app does not seem to be deleted from 'my sync' without performing a manual sync. This leads me to believe that automatic sync may not always be happening, or my understanding of when it is supposed to happen is incorrect.

Lastly, I have a request/suggestion. In fact, it's been a request I've had since my PocketPC days, but never got around to asking for it. I really like the feature which auto-populates a new flight entry with the last date, ident, etc. Would it be possible to add custom fields to that list? For example, one of my custom fields is 'crew name', which would be very useful to be able to carry over from one flight to the next.

Sorry for the long post, but these issues seem to be quite complex, and need a detailed explanation. It's unfortunate, because before the addition of multi-tasking, the app was working flawlessly for me. If there is no fix for these issues in a multi-tasking environment, I, personally, would prefer to go back to the non-multi-tasking version; as it stands right now, multi-tasking seems to be making life more complicated.

Thanks again for your response; I really appreciate your attention to getting these issues resolved.

Cheers,

Chris Brunner
 
Hello Chris,

We have a whole lot of information here, let's see if we can break it down.

I'm going to go out of order here and start with the freezing/wrong screen issue. I just tested this again this morning on a flight from Ottawa, ON to Winnipeg, MB, which are 1 hour apart. I did as you suggested and terminated all apps, followed by a reboot, so that Logbook Pro was the only app running. This time, I didn't experience the weird screen behaviour. I'll keep monitoring it and let you know if the issue pops up again.

I'm glad you were able to clear this, I think it's an iOS 4 issue when it runs low on memory as it seems to be incorrectly suspending "everything" you run which is a design flaw in my opinion.

You mentioned that v1.0.3 fixes the automatic sync issue with multi-tasking. Could you please explain what the new logic is as to when the app will automatically sync?

Sync on Start and Exit is exactly as it sounds, in the world of iOS 4 now in Logbook Pro v1.0.3 on the device it will sync on "Suspend/Resume" which ultimately is the same thing because iOS 4 never closes the app which is why I had to fix it in 1.0.3 for iOS 4 users.

(1) After creating a new flight entry and exiting the app, the flight did in fact appear in my 'my sync' portal; however, upon re-entering the app, the entry still appeared as black, and not in grey which would represent it has been synced.

This is because your entry was not SAVED or committed to the database on the device. When you start an entry and then suspend the app it freezes it. Until you complete the required fields and then tap SAVE will it be commited to the database and become available to sync. This is where you have to be careful not to kill the suspended app if you have not saved as incomplete entries in the suspended state will be lost.

(2) A flight deleted within the app does not seem to be deleted from 'my sync' without performing a manual sync. This leads me to believe that automatic sync may not always be happening, or my understanding of when it is supposed to happen is incorrect.

Deleting the items on the device do NOT delete items once they are synced to your My Sync portal. For now you will have to remove items on the My Sync portal directly before they get synced to Logbook Pro PC edition. I will add a feature request to consider deleting items on the device to also remove them from the My Sync portal via a prompt.

Lastly, I have a request/suggestion. In fact, it's been a request I've had since my PocketPC days, but never got around to asking for it. I really like the feature which auto-populates a new flight entry with the last date, ident, etc. Would it be possible to add custom fields to that list? For example, one of my custom fields is 'crew name', which would be very useful to be able to carry over from one flight to the next.

This has been requested a few times but it's a tough situation as everyone has their own custom info. I'll document the request in the tracker and see if it is something that can be implemented in the future. It is unlikely but I will keep it in mind.

It's unfortunate, because before the addition of multi-tasking, the app was working flawlessly for me. If there is no fix for these issues in a multi-tasking environment, I, personally, would prefer to go back to the non-multi-tasking version; as it stands right now, multi-tasking seems to be making life more complicated.

I think you'll find version 1.0.3 will address this better as it really only affects the sync logic. It does allow you to keep an incomplete flight logged now which was something I was going to implement (and still may) via a "flown" checkbox so you can add new entries, i.e. future flights (ala schedule importer I'm working on) and not have items that do NOT have "flown" checked from make their way to the My Sync portal. In other words a flight has to be "flown" and have all required fields filled in before it can be synced.

Right now I'm a little stuck as to how to use this app. In my ideal situation, I would turn airplane mode ON before departure, enter as much pertinent information as possible while airborne, turn airplane mode OFF again on arrival, and then close out the entry when I have time after that. The whole point of multi-tasking is to be able to enter data as time permits. I can't think of any work-around that solves the problem: If I close out the entry before turning airplane mode back OFF, my data won't sync. If I leave airplane mode ON, I will run into the time zone issue, not to mention that my battery will be dead after 4 hours of searching for signal. If I complete half of an entry and then terminate the app and restart in the new time zone, I will lose my half-completed entry as, in my experience, only synced data will be preserved. The only thing I can think of is to do the whole entry at the end of the flight in the new time zone, but then I may as well just wait until I get home and enter it directly into Logbook Pro on my PC - completely defeating the purpose of the mobile version.

This I believe is the only issue we really have left to hammer out. I may have caused more confusion in my prior "middle of the night" response so let's address this and it's something I need to check into as well based off of your scenario.

First off, if the multi-tasking issue is causing you problems, what I suggested people to do prior to iOS 4 to enter a flight not yet flown is to enter a bogus duration, i.e. 0.1. Then save the flight and come back later and edit it. Even if it's synced, as long as it doesn't get pulled down into Logbook Pro PC edition the My Sync portal will update any time you update the device data. So you could save, kill the app from multi-tasking, come back later and update the flight, but let's see if this is really necessary.

I don't know if what I said before was correct but there is a conversion internally between UTC and local time, it's transparent to you. When entering dates or date/time data you have the option of tapping the blue > button which enters the "now" time, in other words the date and time when you tap that button. So you could effectively land and tap the blue button on the right of the landing time but of course you shouldn't do that! But the point is it will get you close to that time and then you can make the minor adjustment from there. When you made your post I was thinking the app was picking up the UTC offset from the time you first launched the app and then when it suspends and you come back later in a different time zone there could be an issue because the application "may not" be picking up the timezone change. I have to test this scenario.

If all of the above issues have been addressed and we can focus on this one issue, please elaborate on it and tell me exactly what the problem is you're experiencing and let's focus on this. So read what I have posted above and let's whittle this down to what we need to focus on. If you could continue to test any problems with time entries and get back later let me know if there is a problem now that you have 1.0.3 or if all is working as expected.

Thank you for using the forums so others can learn from this as well.
 
Update

Hi Neal,

Once again, thanks for taking the time to write me such a detailed response - it is very much appreciated!

I'm happy to report that things have improved significantly for me in v1.0.3. I had another test run on the trip home to Toronto this afternoon, and JUST about everything worked great.

In response to your last post:

Sync on Start and Exit is exactly as it sounds, in the world of iOS 4 now in Logbook Pro v1.0.3 on the device it will sync on "Suspend/Resume" which ultimately is the same thing because iOS 4 never closes the app which is why I had to fix it in 1.0.3 for iOS 4 users.

This is working great for me now! Any chance you could add some sort of indicator, like the standard iPhone 'spinny wheel', to indicate when a sync is in progress and avoid any potential confusion as to whether or not a sync is taking place?

This is because your entry was not SAVED or committed to the database on the device.

Actually, that's not quite the case. I'm referring to a completed entry that has been saved. Upon suspending and subsequently resuming the app, the entry remains black, although it theoretically has been synced (by the sync associated with the suspend/resume process). I've come to learn, however, that the sync itself has worked fine - it is simply an updating issue on the 'flights' screen. It is not until I cycle the 'all/pending/synced' filter at the bottom to a different filter and then back that the screen actually updates itself and the entry turns grey. Maybe there is a way to automatically refresh the screen upon resuming the app?

Deleting the items on the device do NOT delete items once they are synced to your My Sync portal.

Got it, thanks!

This has been requested a few times but it's a tough situation as everyone has their own custom info. I'll document the request in the tracker and see if it is something that can be implemented in the future. It is unlikely but I will keep it in mind.

OK, I see. Here's to hoping you find a way to make it work!

I think you'll find version 1.0.3 will address this better as it really only affects the sync logic. It does allow you to keep an incomplete flight logged now which was something I was going to implement (and still may) via a "flown" checkbox so you can add new entries, i.e. future flights (ala schedule importer I'm working on) and not have items that do NOT have "flown" checked from make their way to the My Sync portal.

Yes, after my first day of getting acquainted to v1.0.3 this seems to be working quite well to me. Even suspending an incomplete flight entry now seems to be working (would the 'flown' check box you refer to above not simply be another name for the 'synchronized' box at the bottom of the existing new flight screen?). The crashes and strange behaviour reported before seem to have disappeared (at least for the time being) and everything is working according to plan - except, that is, for the persisting time zone issues. As you say, I think we can narrow it down to this one main remaining issue.

When entering dates or date/time data you have the option of tapping the blue > button which enters the "now" time, in other words the date and time when you tap that button.

I fully understand what you're saying about the blue 'current time' arrow, and how this could potentially insert a time in the time zone the app was locked to when opened. That, however, is not my issue. My issue, and what I don't understand, is why when selecting an in/out time from the selector wheel (see 'selector.PNG' attached) and pressing save, the resulting time shown in the associated field ('field.PNG') is shifted by several hours from the time I selected. The images attach show such an example, on a trip from Calgary, AB to Ottawa, ON. The in time selected was 21:20Z, but the resulting time in the associated field was 19:20. The only pattern I can find in this behaviour is that the time shift seems to correspond with the time change from the location where the app was last opened with the phone on, to the location where the phone was once again turned on after the flight. In this case, Ottawa is 2 hours ahead of Calgary, and the resulting discrepancy between selected and indicated times corresponds exactly. This seems to be a pretty consistent situation. In my opinion, the local time, time zone or otherwise is completely irrelevant when manually entering a time in the in/out field. The time that is selected should be the time that is indicated, with no shift occurring.

Hopefully this provides some more information to help you reproduce the problem - although maybe kind of hard while staying in one place (excuse for a vacation?). If you need any more information from me at all, please let me know. My next trip starts on Sunday and will last for 4 days, so lots of opportunity to do some testing.

Thank you for using the forums so others can learn from this as well.

Thank YOU for providing the forum and the excellent support that goes along with it!

Once again, to summarize:

(1) discrepancy between selected/indicated in/out times (possible time zone issue?);
(2) possible addition of 'sync in progress' indicator;
(3) possible addition of screen refresh when resuming the app to update synced flight entries.

Cheers,

Chris Brunner
 

Attachments

  • selector.PNG
    selector.PNG
    45.4 KB · Views: 53
  • field.PNG
    field.PNG
    42.7 KB · Views: 54
Hello Chris,

This is working great for me now! Any chance you could add some sort of indicator, like the standard iPhone 'spinny wheel', to indicate when a sync is in progress and avoid any potential confusion as to whether or not a sync is taking place?

The indicator actually IS set to show and does, the problem (although not) is the sync occurs so fast, it's not recognizable - which is a good thing. In 1.0.2 I actually put in a popup dialog that showed "Synchronizing" with a spinner but it took more time to simply display that info on the device then it did to perform the sync so I removed it in 1.0.3. I am still working to hone that feedback element.

Actually, that's not quite the case. I'm referring to a completed entry that has been saved. Upon suspending and subsequently resuming the app, the entry remains black, although it theoretically has been synced (by the sync associated with the suspend/resume process). I've come to learn, however, that the sync itself has worked fine - it is simply an updating issue on the 'flights' screen. It is not until I cycle the 'all/pending/synced' filter at the bottom to a different filter and then back that the screen actually updates itself and the entry turns grey. Maybe there is a way to automatically refresh the screen upon resuming the app?

Ahh yes, I am aware of this issue and I'm not sure how to resolve it just yet. I'm working on it. True, if you're in one of the data areas it will not refresh the colors based on sync status.

Even suspending an incomplete flight entry now seems to be working (would the 'flown' check box you refer to above not simply be another name for the 'synchronized' box at the bottom of the existing new flight screen?).

No, the "flown" checkbox would indicate that the record (flight) is incomplete and do not check for required fields. It essentially tells the app "leave me alone, I'm not done yet" but I figured "flown" would be a more concise term. :) Synchronized means the flight is valid and sent to the My Sync portal. What I'm gearing up for is schedule importer integration, i.e. the ability to preload future flights and mark them as such (not flown).

I do understand the problem with the timezones and my initial inclination is probably correct. Thanks for the clarification. For now I suggest compensating for the offset until this is resolved, i.e. set a time two hours later as needed. Fortunately it is a rare scenario but one I want to correct nonetheless.

Thank you again and hopefully I can get all this addressed in the next update. I will document all of the items for the tracker and continue to hone this app. It has been a great pleasure creating it and even refining it.
 
Hi Neal,

The indicator actually IS set to show and does, the problem (although not) is the sync occurs so fast, it's not recognizable - which is a good thing. In 1.0.2 I actually put in a popup dialog that showed "Synchronizing" with a spinner but it took more time to simply display that info on the device then it did to perform the sync so I removed it in 1.0.3. I am still working to hone that feedback element.

I thought that may be the problem - well, not really a problem at all. Now that you mention it, I do remember the pop-up for synchronization in v1.0.2, but I see the dilemma. How about simply a status bar at the bottom of the screen (above the tabs) that says something to the effect of "last sync at ..."?

Ahh yes, I am aware of this issue and I'm not sure how to resolve it just yet. I'm working on it. True, if you're in one of the data areas it will not refresh the colors based on sync status.

Sounds good. No biggie, really. Just wanted to make sure you were aware.

No, the "flown" checkbox would indicate that the record (flight) is incomplete and do not check for required fields. It essentially tells the app "leave me alone, I'm not done yet" but I figured "flown" would be a more concise term. :) Synchronized means the flight is valid and sent to the My Sync portal. What I'm gearing up for is schedule importer integration, i.e. the ability to preload *future flights* and mark them as such (not flown).

Ahhhh I see. This is a BRILLIANT idea! The thought of having schedule importer automatically populate your logbook with upcoming flights would be almost too good to be true - especially since you've recently added my airline to your list of supported schedules. ;-) I'm VERY MUCH looking forward to this feature.

I do understand the problem with the timezones and my initial inclination is probably correct. Thanks for the clarification. For now I suggest compensating for the offset until this is resolved, i.e. set a time two hours later as needed. Fortunately it is a rare scenario but one I want to correct nonetheless.

Thanks for taking the time to sort this issue out. While it's not a HUGE deal to have to offset your time entries by a few hours as you suggest, I would have to disagree that it's a rare scenario - for me it occurs practically every flight, and I would imagine I'm not alone. I do hope you'll find an easy fix. On that note, I did another test this morning on a Vancouver to San Francisco leg (all within one timezone); I did not have the time shift problem, which supports the theory that this issue does in fact have something to do with changing timezones.

It has been a great pleasure creating it and even refining it.

I (and I'm sure thousands of other users) really appreciate the amount of care and passion you put into your products. It certainly shows in the resulting quality of the end product, as well as your excellent product support. Now I have one more app for which to look forward to updates. ;-) Keep up the great work!

Cheers,

Chris
 
Chris,

I've duplicated the timezone issue which only affects iOS 4 users that fly across timezones from the time Logbook Pro is first launched and subsequent uses. It will hold the timezone data from the time it's first launched. It's priority for tomorrow's work. I hope to submit 1.0.4 this week, Wednesday if all goes well. Apple is taking about 7 days to approve updates so it will be sometime next week most likely.

Thanks again for the outstanding feedback.
 
Great!

That's great news, Neal! Thanks again for dedicating your time to sorting out this issue. I'm looking forward to v1.0.4!

Cheers,

Chris
 
Chris,

Just as a follow-up...development is going well...I'll reply here when the 1.0.4 update gets pushed to Apple. Probably not until early next week, I'm working on some new features too so it's going to be a few more days.
 
Thanks for the update, Neal. I'm very much looking forward to the update, and to see what 'new features' you have in store! :D

Have a great weekend!

Cheers,

Chris
 
Hello Chris,

1.0.4 is complete. I am going to be testing it throughout the day tomorrow then submit it tomorrow (Sunday) night or Monday. All the issues we discussed are fixed from the timezone issue to the sync status update when you're in a view such as the flights listing, etc. There is a "Synchronizing" popup that appears when the syncing occurs so you get feedback on that. Although syncing takes under a second typically and it takes more time simply to show that dialog, I think it's something the end-user needs to see.

A complete code review was performed to try and catch any errors that may be occurring and also prevent crashes or data corruption. A few new features:

1) In the Flight Log Settings area you'll find a new "Use GMT" on/off switch. Turning it on allows you to enter all dates/times for a flight in GMT instead of device timezone.

2) A new "Pending Flight" checkbox will appear at the bottom of the flight log screen. When checked it allows partial data as validation will not occur and also a pending flight will not be synchronized. This will allow pilots to preload future flights such as an airline trip and then complete it as you go. Pending flights will appear as red in the main flight listing.

3) You can now hide the day and night landing fields and also the simulator field.

I'll put together a complete revision history in the revision history forum sometime in the coming week as it will take Apple 6-7 days to approve the new apps (both iPhone and iPad).

So it's done, just one more day of testing and then I'll push it to Apple for review.

FYI
 
Hi Neal,

WOW - what a list of new features!!!! The option for using GMT is a fantastic idea (I will definitely use this), as is the ability to further customize the fields that are displayed (I will also be taking advantage of these added options). I'm particularly excited, though, about the new 'pending' flight option. We talked about this earlier, but I never thought you'd manage to get this functionality into into this update already - great work! This will be a very useful feature for me (and I'm sure many others), and it will become exponentially more so if you manage to get the scheduler importer integrated in the future.

I'm very happy :D that you were able to get the time zone issue sorted out, as well as the other issues discussed. I agree with you - I think, despite the impracticality of displaying a sync notification that takes longer than the sync itself, it is an important element of feedback for the user. I know I, for one, will appreciate it! Thanks again for spending the time to work with me to get these issues resolved - I very much appreciate it. I've said it before and I'll say it again: it's very much a testament to the superior end result of your products.

Looking forward to the release of the update!

Cheers,

Chris
 
Hello Chris,

Just a follow-up that Apple still hasn't touched the updates. It's still in "waiting for review" state. The dreaded waiting game with Apple, you never know why it takes so long! Some cycles its fast, some it's 7-9 days. Once I hear from Apple I'll reply again.
 
Thanks very much for the update, Neal. Fortunately (unfortunately) I'm well acquainted with the Apple waiting game. When you're eagerly awaiting an update, it seems to take forever - like watching water boil. My next trip isn't until Thursday anyway, so hopefully by then it'll be available in the App Store!

Cheers,

Chris

:cool:
 
Hello Chris,

The iPhone and iPad updates both went "into review" earlier today. No news is usually good news, I'm hoping release is imminent but I have seen apps sit "in review" for a day or two as well, so we'll just see. Hopefully a release tonight.
 
Version 1.0.4 has been approved for both iPhone and iPad and should be on the App Store in the next few hours, if not sooner.
Thanks, Neal. I've already downloaded and installed the update - thank you VERY much for the new features and enhancements!!!! I'm excited to take it for a 'test flight' tomorrow afternoon when I return to work. I'll report back with the results.

Thanks again,

Chris

:cool:
 
Back
Top