Quicken for Mac 2018 v5.7.0 & 5.7.1 Released
Quicken Marcus
Employee ✭✭✭✭
Today I’m excited to announce that we’re releasing Quicken for Mac 5.7. There’s a lot of great improvements in this release.
First off, performance. Launch times should be greatly improved. We also improved the performance of the portfolio view chart which was a little sluggish if you had lots of historical investment data.
We continue to refine our Bills & Income experience. If you haven't tried it yet, give it a try. The feature automatically updates your bills with the latest balance information so you can see how much you owe without having to go to the biller website. This is especially useful for credit cards and utility bills that change every month. You can also view and download PDF statements for top billers all from within Quicken. In 5.7, we've added the ability to refresh the Bills & Income view without having to do a full download of transactions and bills now tell you if they are waiting for the next bill so you know that Quicken hasn't downloaded the latest balance yet.
We also fixed a number of issues brought up here in the forums. For example, we fixed an issue where comparison reports with time periods of different lengths weren't quite working right. We also fixed a number of issues with dividends, interest income, reinvested dividends, reinvested interest, long-term capital gains and short-term capital gains where they weren't showing up in the All Transaction view and in reports. We also fixed the Gain/Loss calculations in the portfolio view when there were splits.
Some new things we added are the ability to set an investment account as a Roth IRA or Roth 401k. Also, we launched our new mobile app today which includes budgets. I think you'll be able to download it now for Android and it will take a few days for Apple to approve it for iOS devices.
You can always find our release notes here. They may not be up yet but should be there shortly.
UPDATES
7/19 - Staged release.
7/19 - Pausing release. We're seeing a few people running into a crash so we're going to stop the release to investigate.
7/19 - Pausing budget sync. The crash is in budget sync so we're turning that feature off. This means you won't be able to see budgets on the new mobile app but it does mean those that were in this situation will be able to sync again. A small percentage of customers who upgraded ran into this crash. The issue was also in 4.7.2 so turning off budget sync fixes this issue for 2017 customers too. We'll turn on budget sync again as soon as we can.
7/20 - We're starting the rollout again. The new version number is 5.7.1. This includes a fix for budget sync.
7/21 - Budget sync turned on for 5.7.1.
7/21 - Unfortunately, it still looks like people are crashing when syncing their budgets so we're going to have to turn it off again. I also pulled the release for now.
7/22 - We're starting to roll out 5.7.2 to customers. This fixes the top 3 crashing issues we were seeing in 5.7.x. 1) A crash when syncing budgets. 2) A crash when editing the payee and auto-fill had bogus data. 3) A web connect file import issue if the bank includes invalid error codes.
First off, performance. Launch times should be greatly improved. We also improved the performance of the portfolio view chart which was a little sluggish if you had lots of historical investment data.
We continue to refine our Bills & Income experience. If you haven't tried it yet, give it a try. The feature automatically updates your bills with the latest balance information so you can see how much you owe without having to go to the biller website. This is especially useful for credit cards and utility bills that change every month. You can also view and download PDF statements for top billers all from within Quicken. In 5.7, we've added the ability to refresh the Bills & Income view without having to do a full download of transactions and bills now tell you if they are waiting for the next bill so you know that Quicken hasn't downloaded the latest balance yet.
We also fixed a number of issues brought up here in the forums. For example, we fixed an issue where comparison reports with time periods of different lengths weren't quite working right. We also fixed a number of issues with dividends, interest income, reinvested dividends, reinvested interest, long-term capital gains and short-term capital gains where they weren't showing up in the All Transaction view and in reports. We also fixed the Gain/Loss calculations in the portfolio view when there were splits.
Some new things we added are the ability to set an investment account as a Roth IRA or Roth 401k. Also, we launched our new mobile app today which includes budgets. I think you'll be able to download it now for Android and it will take a few days for Apple to approve it for iOS devices.
You can always find our release notes here. They may not be up yet but should be there shortly.
UPDATES
7/19 - Staged release.
7/19 - Pausing release. We're seeing a few people running into a crash so we're going to stop the release to investigate.
7/19 - Pausing budget sync. The crash is in budget sync so we're turning that feature off. This means you won't be able to see budgets on the new mobile app but it does mean those that were in this situation will be able to sync again. A small percentage of customers who upgraded ran into this crash. The issue was also in 4.7.2 so turning off budget sync fixes this issue for 2017 customers too. We'll turn on budget sync again as soon as we can.
7/20 - We're starting the rollout again. The new version number is 5.7.1. This includes a fix for budget sync.
7/21 - Budget sync turned on for 5.7.1.
7/21 - Unfortunately, it still looks like people are crashing when syncing their budgets so we're going to have to turn it off again. I also pulled the release for now.
7/22 - We're starting to roll out 5.7.2 to customers. This fixes the top 3 crashing issues we were seeing in 5.7.x. 1) A crash when syncing budgets. 2) A crash when editing the payee and auto-fill had bogus data. 3) A web connect file import issue if the bank includes invalid error codes.
0
This discussion has been closed.

Comments
Some users also assume that a problem they are experiencing is universal, when the reality is that (a) not all users use that feature and (b) sometimes the issue is caused by something unique to that user's data or software or hardware, so other users aren't experiencing the same problem.
The developers have to sort through all of that, and then decide what to address next, and next, and next after that. Sometimes, those decisions aren't a straight line, either. For example, users have complained about why Quicken Mac isn't more flexible about budgeting for transfers (like paying loans, or building savings). Marcus shared that while they acknowledged this was something they needed to address, they wouldn't tackle it until the Quicken Cloud team was done rebuilding the mobile app's handling of budgets, because they'd likely need to rework part of the Mac app's budget code to align with the mobile app. So this might have been categorized as a high priority, yet delayed because of other pieces.
Similarly, adding or fixing a particular feature might rely on changes to the database or changes to user interface or changes to back-end processes, all of which are done by different engineers on the development teams, any of whom might be tied up on a different project for awhile. For example, we all know that revamping the reports in Quicken Mac has been a high priority, and is an ongoing project that has been getting worked on over the past year. If the developers who deal with printing output are tied up on that high-priority project over a long period of time, perhaps that's why they haven't gotten to work on making changes to the printing of checks. Or perhaps printing checks is scheduled to switch from the old printing architecture (created for Quicken Essentials over seven years ago) to the new printing architecture that has been partially implemented for some reports over the past year, and they had to finish the underlying printing code before going back to checks to re-write that piece of the code. (Those are hypothetical examples; I'm not saying that's what's actually happened regarding Joseph's area of need.)
And sometimes, if not many people are squawking about a problem, it just gets assigned a lower priority, or falls off the radar. That's why re-posting an issue here, as Joseph did, isn't such a bad thing to try to catch Marcus' eye.
Marcus needs to be perpetually aware of many hundreds of user requests, plus many internal things they know they need to work on, figure out the dependencies in code development, and allocate projects based on each developer's particular skills/knowledge/areas of expertise.
Put all that together and you get some sense why something that appears incredibly simple -- like making the fonts on a check bigger or bolder -- might (a) be more complicated than it appears, (b) be something very few users have indicated is a problem for them, or (c) have been accidentally lost in the shuffle of dozens of projects and programmers. It doesn't diminish the pain/annoyance of an issue affecting you, but maybe it helps you realize it's not an issue of the developers being dumb or refusing to deal with an issue.
Your question is much easier to answer: whenever they feel they have fixed what was causing the problems. Marcus's note above talks about issue with the budget on the mobile app, so if that was the only issue, they may not need to change the Mac program. Typically they release to 1,000 people a day for 2 or 3 days, monitoring closely to see if any problems show up which were not caught during beta testing. If things seem okay after 2 or 3 days, they "open the spigot" and everyone gets the update; if they find problems, there are sometimes x.x.1 or x.x.2 minor fixes that get released over the the next day or two, and sometimes they pause for a few days until they have found and fixed the problem.
During the staged release period, there's no particular time or way to know when the spigot will be opened to let another 1,000 users download the update or when it will get turned off.
My philosophy of this is: don't complain if the downloads have been stopped and you didn't get the new version; it was stopped because someone else got it and ran into a problem! It's rarely more than a week, and sometimes half that, between the announcement of a new release and it being available to everyone.
What I mentioned to Mr. Toubes is that we would investigate it while working on report printing. If we add font and font size capabilities to reports we could add them to checks too because it's pretty similar. We're still working on report printing, but I'm afraid the ability to print a report to fit on a page is taking longer than I expected and its impacting other things I wanted us to start this month meaning I'm thinking we won't get to fonts in reports or checks.
What do others think? Are you also having the same issue where the check font is hard to read and the post office is returning the check? It would be great to see the idea voted on in these forums. The highest voted "check" related idea that I can see is "match downloaded checks to checks already recorded". Mr. Toubes, you mentioned there were other people who have expressed the same issue in the forums. Can you point me to the forum post so I can see the number of people this is impacting? I see this post "quicken for Mac 2016... How do you change the font size for reading and writing and printing checks...". I meet with our Care team every week and they tell me about a number of check issues customers are running into and I haven't once heard them tell me about this issue. I'm not saying it doesn't happen but the Care team is another input I use to decide what gets worked on and when.
Anyway, it would be great if others weighed in on the importance of this feature. What I have planned is to start working on renaming rules so doing fonts for checks would bump that work. There are always trade-offs.
I only post this because I think it is helpful if people understand what other people are seeing. I certainly wouldn't object if there was an option somewhere to set the size for the address, but I wouldn't feel I need it.
Updated to Mac Version 5.7.1 and encountered new issue editing Transactions Category when in All Transactions Tab. When selecting any of the Filters, and opening the Transaction, I am unable to see, nor modify the Category. A work around is to edit the Details/Split, where you can enter or modify the Category.
In the left rail, I click All Transactions at the top. In the register, I'm on the Transactions tab. I set a filter for the current year and for one account. I can still see the category column, and if I click on a split transaction, I see all the splits and their categories. If I double-click to edit a transaction, whether it's a split or not, I can edit the categories like normal.
When you first click on All Transactions, the the Category column even present? If not, there's an easy solution to that: click the Columns icon in the bottom toolbar, and click on Category to make it a visible column. "All Transactions", like every individual account register and grouped account register, is individually configurable, so it's sometime easy to overlook that a missing column may not be there by default but can easily be turned on.
If that's not it, please add more detail about what you're doing and seeing. Or if you can capture a screen shot with no important personal data, please post that.
Problem solved. Thank you.
I'm not seeing zero values in mine:
This is grouped by security, but the values are not zero if I switch the view to type, asset class, or holding period. Is this where you're looking, or are you talking about somewhere else?
Most of this info is available on a million websites, so it isn't critical like the overall Gain/Loss $ & %, which is working fine. But I do like having it all there at a glance
Thanks again for your comments.
And if I set the Price and Holdings date back a month (before most my funds had quarter-end reinvestments), I still got what seems to be valid values for funds that did not have any transactions in the prior month (e.g. just showing change in value). I haven't sat an analyzed the numbers for accuracy; I'm just reporting that I'm seeing non-zero numbers for all but a money market fund that is showing all zeros.