Well, if you think of your browse page (interface) as horizontally fixed, but vertically variable, it may help in your design decisions. The browse page is based upon the number of columns you use to establish the width and an aspect ratio that determines the height of the boxes (squares or rectangles or even just text areas - if you opt for no image) that will fill the space. The fewer the columns and balance of the aspect ratio (1:1, 1:2, .5, .375...), or wherever the second number is getting larger), the less grid resolution you have to work with in your grid. The more columns you add and greater aspect ratio (2:1, 3:1, 1.5), the more grid resolution you'll have to work with. Then, within that grid, you can layout whatever types or shapes of cards you'd like (as long as they conform to the grid).
The part that varies (across platforms) is where "the fold" lies. That's going to fluctuate across devices, so, if you know you want something to appear above the fold, make sure you keep it in the upper most part of your layout.
This obviously doesn't cover everything, but I hope it helps to get you started...
One more thing that I like to consider within browse page design is the added depth you can add by including a browse page background image, transparency (in banners, or article cards) and margins & gutters... We did this on the Working At Exxon Mobile home collection and it adds a sense of depth with the text and images scrolling over a visible background.
I'd add that shifting the thought from iOS and Android to phone and tablet is really important.
We don't design articles or collection browse pages for iOS and Android, DPS 2015 doesn't support "renditions" the way DPS 2014 did.
Your project has either one or two top-level collections for navigation on either all devices or phone and tablet -- the two top-level system is about the device class, not the OS.
If you generate HTML articles with appropriate code to be flexible for these two classes, the HTML article will adapt to the device.
If you generate page-based, pixel-perfect articles, the size of the page will scale to fit on the device screen.
If you generate smooth scrolling, pixel-perfect articles, you can export the article for a tablet (iPad) AND export again for a phone. And then in parallel collection/article structures you load the phone articles into the phone hierarchy and iPad into the tablet hierarchy -- and each will scale to fill on that device class.
I find it's better to think about device class more than device platform.