Long story short, Windows Phone's browsers don't support the web reader so there's no way to read JNC prepubs. Well, there is now, but the app is not really finished and I won't have time to work on it for a while.

It totally works and you can check it by installing from Windows Store (available only through the link on top—lack of in-app explanations about prepub system and such makes it newcomer-unfriendly).

Here's a video, and here's a couple of screenshots because the video is blurry:

@sam-pinansky The hard part is what comes after login. Other series won't work that well with current volume list layout and I'd need to make a list for recent parts/favorite series etc. which is a bit complicated. There are non-UI things as well but those are simple enough.
After all, this is a pretty big step to do, so I decided to polish Rokujouma-only version before moving to other series.

Small-ish update: there's a login page now which unlocks the rest of JNC series and access to members-only parts. Reading progress is synced but isn't shown anywhere (I plan to make it visible on the list of individual volume's page and recent parts page but those don't exist yet). Part loading is much faster now. Network interaction is faster as well, though it's a bit buggy (fixed in later builds).

App is available in store through direct link. Submission took six days, hopefully it won't take that long next time. I fixed a number of minor bugs and did useless additions by now, expect a minor update soon.

@_08 Oh, FYI if you want your app to get the list of parts for the "launch titles" special, the way I fixed the bug you pointed out is a bit of a server side hack: It tests for the .where.and query and if it exists and the series has the override expired flag, it overwrites the query with just where: {seriesID: ID},
if you do some query without the "and" logic it won't trigger the hook.

In the future we'll fix this on the app side, but for now this makes it work. Depending on how your app queries the back end you might have the same issue our app once did.

@sam-pinansky The only server-side filter I use is filter by uploading date to separate old/new records for better caching (old retain e-tag and get pulled from cache while new are pretty fast to update), so the app should be fine as long as that works. Expiration gets checked on client. I don't need expired parts that much, but things are pretty fast and cheap as they are now (except the part where request for all parts takes like 4 seconds on a server to complete - not perceivable at client's side but potentially bad for server if it actually takes 4 seconds of its resources).

@_08 It's definitely getting a little heavy to return all parts. There's various optimizations I can do to improve the speed of that like not include all the part metadata by default or cache some of the dynamically generated properties, etc.

The easier solution for the short term is just split up the requests on the client into paginated chunks, and to prevent hammering the backend enforce some kind of part limit.
All in good time.

@sam-pinansky Pagination won't work well because the point was to request the whole thing to be able to instantly return the list of parts and volumes for any given volume or serie as soon as user user clicks on it, without any network interaction.
If it ever becomes actually necessary I can increase time between "heavy" updates without hurting usability (it's set to whenever user navigates but only if 30min passed after previous update, "light" updates are after 30sec) but even now it won't request much more than official app and I'm like the only one who uses it anyway.

@reyth No party here – stats from winstore and such are extremely low. Development is slow as well because I don't have time and app does most of things I needed.
The new version is in the process of submitting, though.

First impression of the Android build is pretty positive, yay night mode!

It seems to keep track of the last read position better than the official app. I jumped back in the official app to see what part of VRMMO I was reading so it lost the place and I had to manually swipe to the percentage to get it back. This app however opened that part to where I was straight away.

Might be the web reader is better at that than the official Android app and this app is more directly using the web reader?

@smashman42 Reading progress is stored as a number between 0 and 1 everywhere, but interpretation is different. In my app it corresponds to top paragraph (first character of first visible paragraph divided by total chars) while web reader and official app is something like page number divided by total pages (even in scrolling mode). Latter is obviously less precise and it also depends on page layout meaning your position will drift if you change font, reader's size or screen orientation.
Unrelated to precision, the feature is totally broken in the official android app right now.